DragonFlyBSD Kernel Audit
DF-0850 / fix_run.log
← back to finding ↓ download raw
=== DF-0850 FIX VALIDATION RUN (patched ext2fs.ko module) ===
Kernel: DragonFly 6.5-DEVELOPMENT #0 (unpatched kernel binary)
Module: ext2fs.ko with fix.diff applied (interior node limit validation + block 0 re-lock prevention)
Module SHA256: 5c7a91ab9ec68fae49e3fc21c5cdea919de7669fcf8eea56b8184ebac6d29674

Test images:
  V1: header.h_blk=0, count=1 (causes "lockmgr: locking against myself" panic on unpatched)
  V3: header.h_blk=573, count=1 (exercises interior node OOB read path on unpatched)

--- V1 image test (stat f0000) ---
stat: /mnt/df0850/testdir/f0000_longname_to_force_htree_index_split: stat: No such file or directory
RC=1
(GUEST UP, NO PANIC)

--- V1 image test (stat f0050) ---
504432647 63 -rw-rw-rw- 1 root wheel 4294967295 0 "Jul 11 13:21:05 2026" ...
RC1=0
(FILE FOUND via linear scan fallback, NO PANIC)

--- V1 image test (stat nonexistent) ---
stat: /mnt/df0850/testdir/nonexistent: stat: No such file or directory
RC2=1
(NO PANIC)

--- V3 image test (stat f0000) ---
RC=1
(NO PANIC)

--- Final status ---
Guest: UP
Panics in boot.log: 0

=== RESULT: FIX VALIDATED ===
The V1 image which reliably triggers "panic: lockmgr: locking against myself"
in ext2_htree_find_leaf on the unpatched kernel does NOT panic on the patched
kernel. The fix's two checks catch the corrupt image:
  1. ext2_htree_get_block(found) == 0 -> goto error (prevents re-lock of root)
  2. ext2_htree_get_limit(entp) != ext2_htree_node_limit(ip) -> goto error
     (prevents OOB binary search on interior node with limit=0xFFFF)
The htree lookup returns -1, ext2_htree_lookup returns -1, and the caller
falls back to a linear directory scan (which succeeds for existing files,
returns ENOENT for missing ones).