radix_node_head leak on table_delete and on table re-create enables kernel memory exhaustion DoS
Summary
table_delete_dispatch sets type=0 and rn_flush node tree but never frees radix_node_head structures themselves XXX comment. table_create_dispatch unconditionally calls rn_inithead on both mask and node overwriting pointer without freeing prior heads. Repeated create->delete cycles leak 2*sizeof(radix_node_head)(~600 bytes) per cycle per CPU no upper bound. ip_fw3_table_fini_dispatch repeats same XXX. [VERIFIED pass2: REFUTED - rn_inithead is idempotent so re-create reuses retained heads and retention is bounded, 20000 create-delete cycles moved zero pages; bonus captured delete-without-create rn_flush NULL panic VA 0x28]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2581 · 3 files| File | Type | Description | Size | |
|---|---|---|---|---|
| fw3_table_leak.c | — | 2.8 KB | view raw | |
| run.log | — | 2.9 KB | view raw | |
| delete_panic_bonus.txt | — | 26.7 KB | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Evidence (decisive lines)
fw3_table_leak.log: 20000 cycles, zone_kmem_pages 64->64; fw3_table_delete_panic.txt: rn_flush(NULL) panic VA=0x28
PoC changes
raw setsockopt table ops + memory sysctl metrics
Verified recommended fix
rn_freehead the per-table heads in fini (hardening); separately fix the delete-without-create NULL deref
Verdict
The claimed unbounded leak is refuted: rn_inithead (net/radix.c:1247) is IDEMPOTENT (if (*head != NULL) return 1), so table_create_dispatch on an existing table reuses the retained heads rather than leaking the prior ones; table_delete_dispatchs missing rn_freehead leaves the heads CACHED per (cpu, table-id), bounded by 128 tables x ncpu x 2 heads (~hundreds of KB worst case), not unbounded. Empirical: 20000 create/delete cycles through the real IP_FW_TABLE_CREATE/DELETE sockopts left vm.zone_kmem_pages and free-page counts unchanged. Bonus defect observed while testing (NOT DF-2581, filed for the record): ipfw3 table N delete on a NEVER-created table calls rn_flush(NULL,...) -> deterministic NULL-deref panic (fault VA 0x28, netisr context) -- separate report-worthy bug.
No comments yet.