DragonFlyBSD Kernel Audit
DF-0763 / run.log
← back to finding ↓ download raw
# DF-0763 run log — decisive baseline reproduction on the UNPATCHED kernel
# Kernel: DragonFly 6.5-DEVELOPMENT #0 (with-src baseline, INVARIANTS ON)
# Trigger: mount crafted hammer2 image with sroot_blockset[0].data_off radix=17
#           (bytes = 1<<17 = 128KB, exceeds HAMMER2_PBUFSIZE=64KB)
#
# Command sequence run as root over ssh (vm.sh run_root):
#   vnconfig -c vn0 /tmp/h2_craft_radix17.img
#   mkdir -p /mnt/h2test
#   mount -t hammer2 /dev/vn0@testvol /mnt/h2test    # <-- PANICS HERE
#   ls /mnt/h2test
#
# The ssh session hangs (guest enters DDB).  The panic signature is captured
# in the serial boot log (dfbsd-qemu/boot.log) because comconsole is baked in.
# Below is the relevant excerpt from dfbsd-qemu/boot.log:

---8<--- dfbsd-qemu/boot.log (panic excerpt) ---

hammer2_mount: devstr="/dev/vn0@testvol"
hammer2_mount: device="/dev/vn0" label="testvol" rdonly=0
hammer2_ondisk: "/dev/vn0" zone=0 id=0 offset=0x0000000000000000 size=0x0000000004000000
hammer2_mount: "/dev/vn0": no recovery needed
hammer2_mount: hmp=0xfffff80119c04000 pmp=0xfffff80118f00000
HAMMER2: VOLDATA DUMP
HAMMER2: INITIATE SPANs
Illegal: 0000000001400000 0000000001400000+00020000 / ffffffffffff0000
panic: assertion "pbase != 0 && ((lbase + lsize - 1) & pmask) == pbase" failed in hammer2_io_alloc at /usr/src/sys/vfs/hammer2/hammer2_io.c:126
_hammer2_io_getblk() at _hammer2_io_getblk+0xc6 0xffffffff80964d46 
_hammer2_io_getblk() at _hammer2_io_getblk+0xc6 0xffffffff80964d46 
_hammer2_io_bread() at _hammer2_io_bread+0x17 0xffffffff80965397 
hammer2_chain_load_data() at hammer2_chain_load_data+0x2a5 0xffffffff8096f4a5 
hammer2_chain_lock() at hammer2_chain_lock+0xde 0xffffffff8096fa4e 
hammer2_chain_get() at hammer2_chain_get+0x45 0xffffffff80970685 
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db> 

---8<--- end excerpt ---

# Reproduction is deterministic: the panic fires every time the crafted
# image is mounted, on the very first chain_get/chain_lock of the super-root
# inode (whose sroot_blockset[0] blockref has the bad radix).  vm.sh status
# => down after the trigger.  Confirmed on two independent runs (initial
# discovery + baseline re-confirmation after a fresh vm.sh reset with-src).