DragonFlyBSD Kernel Audit
DF-0670 / run.log
← back to finding ↓ download raw
=== 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.