DragonFlyBSD Kernel Audit
DF-2649 / panic_getvolume.txt
← back to finding ↓ download raw
panic: no volume for offset 0x0000000100000000
cpuid = 0
Trace beginning at frame 0xfffff8011920eea8
hammer2_get_volume() at hammer2_get_volume+0x4b 0xffffffff8098726b
hammer2_get_volume() at hammer2_get_volume+0x4b 0xffffffff8098726b
_hammer2_io_getblk() at _hammer2_io_getblk+0x477 0xffffffff809650f7
_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
Debugger("panic")

CPU0 stopping CPUs: 0x0000003e
 stopped
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db>
----
[provenance] verbatim `dfbsd-qemu/vm.sh log 60` serial-console capture,
DF-2649 run #1 on the stock INVARIANTS kernel #0 (guest DragonFly
6.5-DEVELOPMENT #0 X86_64_GENERIC, Thu Jul 2 06:02:54 UTC 2026), image
craft2649_v1.img (PFSROOT poison bref, data_off=0x10000000a), trigger
run as uid 65534 via HAMMER2IOC_BULKFREE_SCAN.

The backtrace proves hammer2_bulkfree_scan recursed into the forged
PFSROOT chain and called hammer2_chain_lock -> hammer2_chain_load_data
-> _hammer2_io_bread on it.  The panic itself is DF-0875's (out-of-range
data_off, hammer2_get_volume); with an *in-window unreadable* offset
(real media error) this same call returns EIO with chain->data == NULL
and the scan then dereferences parent->data->ipdata.filename at
hammer2_bulkfree.c:146 (and :398) -- the DF-2649 crash site.