# #41978 \[BC-Insight] Values of the current gc\_slot can be garbage collected in edge case **Submitted on Mar 19th 2025 at 18:30:52 UTC by @HollaDieWaldfee for** [**Attackathon | Movement Labs**](https://immunefi.com/audit-competition/movement-labs-attackathon) * **Report ID:** #41978 * **Report Type:** Blockchain/DLT * **Report severity:** Insight * **Target:** * **Impacts:** * Causing network processing nodes to process transactions from the mempool beyond set parameters ## Description ## Brief/Intro When the transactions in flight are garbage collected, values that have expired should be removed. But in certain cases, this even removes values of the current gc\_slot that have not expired yet and have just been added. ## Vulnerability Details Let's take a look at how this happens. Every time a transaction is received and added to the mempool, the transactions in flight are garbage collected, if enough time has passed after the last time they have been garbage collected. This can be verified by taking a look at reference (1). Inside of `gc()`, all slots that are too old are removed. However, if `self.value_ttl.get() / self.gc_slot_duration.get()` rounds down to zero, the current slot will be removed as well even though it has not expired yet. As a result, values that have not expired will be garbage collected. In contrast, the garbage collector for the `used_sequence_number_pool` correctly only removes slots until the current one. To verify this, please take a look at reference (4). Given this difference to reference (4), the garbage collection for in-flight transactions is clearly flawed and does not meet the security guarantees - that the current slot can't be removed - that the sequence number garbage collector meets. ## Impact Details Values that have not expired will be garbage collected. Hence, the amount of transactions in flight will be lower than it should and more transactions are allowed to be submitted. ## References (1): (2): (3): (4): ## Proof of Concept ## Proof of Concept 1. A new transaction is received and successfully submitted. `transactions_in_flight.gc()` is called since `self.last_gc.elapsed() >= GC_INTERVAL`. Again, this can be verified by taking a look at reference (1). 2. As showcased in reference (2), this function calculates the `slot_cutoff` in the following way: `gc_slot.saturating_sub(self.value_ttl.get() / self.gc_slot_duration.get())`. If `self.value_ttl.get() / self.gc_slot_duration.get()` rounds down to zero, the `slot_cutoff` will be the current `gc_slot`. This means that only the slots after the cutoff will be kept and all of the other slots, including the current slot, wll be removed (reference (3)). 3. Now, the current slot will be removed even though it has not expired yet. As a result, the amount of transactions in flight will be decreased by too much and allows more transactions to be submitted than it should. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://reports.immunefi.com/movement-labs-attackathon/41978-bc-insight-values-of-the-current-gc_slot-can-be-garbage-collected-in-edge-case.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.