DF-0670 / run.log
=== DF0670 TEST START ===
Sun Jul 19 05:36:37 UTC 2026
ipfw3 initialized, default to deny
ipfw3 module basic loaded
[sizeof user ipfw_ioc_table = 44]
[DF-0670: short-buffer CREATE -> OOB read of ioc_table->type and ->name]
=== RUN 0 ===
create(valsize=4) rc=0 errno=0
list rc=0. table_ctx[0].id=0 type=0x00000000 count=0
table_ctx[0].name (32 bytes) (32 bytes):
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=== RUN 1 ===
create(valsize=4) rc=0 errno=0
list rc=0. table_ctx[0].id=0 type=0x00000000 count=0
table_ctx[0].name (32 bytes) (32 bytes):
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=== RUN 2 ===
create(valsize=4) rc=0 errno=0
list rc=0. table_ctx[0].id=0 type=0x00000000 count=0
table_ctx[0].name (32 bytes) (32 bytes):
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=== DF0670 TEST END ===
---
INTERPRETATION:
The OOB read code path IS executed (setsockopt returned 0 — the
CREATE dispatch ran; table_create_dispatch read ioc_table->type at
offset 4 and ioc_table->name at offset 12..43 of a kernel buffer
kmalloc'd for only 4 user-supplied bytes; kmalloc(4) on DragonFly
returns an 8-byte slab chunk, so offsets 4..7 are within-chunk and
offsets 8+ read adjacent slab chunks).
However, on this guest configuration:
- table_ctx->type read as 0x00000000 (the slab allocator returns
zeroed bytes for the small chunk region; adjacent slab chunks are
either freshly zeroed or freed-and-poisoned but the first 4 bytes
of the next chunk happen to be 0 here)
- strlcpy(table_ctx->name, ioc_table->name, 32) saw a leading NUL
byte at ioc_table->name[0] and wrote only the NUL terminator
=> No actual info leak observed in this PoC run (0 non-zero leaked
bytes). The bug (missing sopt_valsize validation) IS confirmed by
source trace; the practical info leak depends on non-zero slab
residue at offsets 4-7 and 12+ of the small kmalloc chunk, which is
not the steady state on this guest.
The structural bug (no validation) is real and the OOB read code
path IS taken; the practical exploit ceiling (kernel-pointer leak)
would require heap grooming to populate adjacent slab chunks with
attacker-observable data.