## Summary `bundle_block_free` frees a block's EID reference list as a single node and never calls `eid_free`. By doing so, every BPv6 block with more than one EID reference leaks all list nodes after the head and every EID string the references resolved to. The reference count is unbounded and each two-byte reference can resolve to its own copy of a dictionary string of up to 32 KiB.A bundle of a few tens of kilobytes leaks hundreds of megabytes that are never reclaimed. The leak occurs whenever the bundle is freed, valid or not, meaning any peer that reaches the mtcp, smtcp or TCPCLv3 convergence layer can exhaust the node's memory without authentication. ## Details `bundle_block_free` in `components/ud3tn/bundle.c` treats `eid_refs`, a singly linked `struct eid_list`, as one allocation: ```c void bundle_block_free(struct bundle_block *b) { if (b != NULL) { if (b->eid_refs != NULL) free(b->eid_refs); ... ``` The BPv6 parser builds that list in `bundle6_parser_read_byte` in `components/bundle6/parser.c`, allocating one node per reference and pushing it onto the head: ```c case PARSER_STAGE_BLOCK_EID_REF_SSP: ... struct eid_list *entry = malloc(sizeof(struct eid_list)); ... entry->eid = bundle6_read_eid(state->dict, state->dict_length, state->cur_eidref); ... entry->next = (*state->current_block_entry)->data->eid_refs; (*state->current_block_entry)->data->eid_refs = entry; ``` The reference count is read with `sdnv_read_u32` and has no upper bound. When the primary block carries a dictionary, `bundle6_read_eid` resolves each reference through `eid_from_string` into a separate heap copy of the referenced string, up to `EID_MAX_LEN` bytes, and none of these allocations is counted against `BUNDLE_MAX_SIZE`. Note that `bundle_block_dup` in the same file walks the list correctly,only the free path does not. Every block is released through `bundle_free` or `bundle_reset` which reach `bundle_block_free` via `bundle_block_entry_free`. This happens after delivery or deletion, on validation failure in `bundle_send`, on a parser error and when the connection closes mid-bundle, so the leak does not depend on the bundle being valid, routable or complete. ## Proof of concept The following BPv6 bundle leaks memory when delivered to the node's mtcp convergence layer: ``` 06 00 1d 00 04 00 04 00 04 00 04 00 00 00 11 64 74 6e 00 2f 2f 61 2f 41 41 41 41 41 41 41 41 00 01 48 04 00 04 00 04 00 04 00 04 01 00 ``` The primary block carries the dictionary `dtn\0//a/AAAAAAAA\0`. The payload block (`01 48`) sets `LAST_BLOCK` and `HAS_EID_REF_FIELD` and declares four EID references (`04`), each `00 04`, which resolve to `dtn://a/AAAAAAAA`. Under LeakSanitizer the node reports 164 bytes leaked in 7 allocations once it exits: three list nodes and four EID strings. The leak scales with the reference count and the dictionary string length. For instance, on a release build the same layout with 1,000 references to a 32,000-byte EID (34 KB on the wire) adds about 32 MB of resident memory per bundle and a single 92 KB bundle with 30,000 references adds 963 MB. The bundle needs no valid destination and is not required to complete. It only has to reach a convergence layer the node listens on. ## Impact A remote unauthenticated peer can permanently consume the node's memory at roughly 1,000 to 16,000 bytes per byte sent. The memory is not reclaimed when the bundle is deleted or the connection closes so a short burst of bundles exhausts available memory and the µD3TN process is terminated, stopping all bundle processing on the node. ## Remediation The issue has two sides that need to be fixed: the leak and the amplification. To fix the leak, walk the list in `bundle_block_free` and release each EID: ```c struct eid_list *ref = b->eid_refs; while (ref != NULL) { struct eid_list *const next = ref->next; eid_free(ref->eid); free(ref); ref = next; } ``` On the amplicifation side, the parser should also account for the memory each resolved EID reference allocates and reject the bundle when it exceeds a certain limit, as it already does for `BUNDLE_MAX_SIZE`.