================================================================ DF-0074 - DIOCGSLICEINFO heap overflow -> kernel PANIC capture Guest: DragonFly 6.5-DEVELOPMENT master DEV DragonFly v6.5.0.1712.g89e6a-DEVELOPMENT #1: Mon Jun 29 14:18:01 UTC 2026 x86_64 / X86_64_GENERIC Source: dfbsd-qemu/boot.log (serial console, comconsole baked into baseline) ================================================================ Both panics below are direct consequences of the DIOCGSLICEINFO heap overflow at sys/kern/subr_diskslice.c:557, which bcopy()s 130 slots of struct diskslice (256 B each) into a 16-slot destination buffer (4128 B), writing 29184 bytes (~28 KB) of attacker-influenced data past the end of an M_IOCTLOPS slab object and corrupting adjacent slab zones. ---------------------------------------------------------------- [ Run 1 ] fresh boot (vm.sh reset -> clean-install) attach overflow.img + single trigger + 5-iter stress + 16-proc flood ---------------------------------------------------------------- The trigger returned nslices=130 on every iteration (overflow happened each time); the guest then froze ASYNCHRONOUSLY while the idle slab-cleanup reclaimer walked zone metadata smashed by the overrun: Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic id = 1 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff80655e49 stack pointer = 0x10:0xfffff800649fc970 frame pointer = 0x10:0xfffff800649fc9b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 0, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle current thread = pri 12 (CRIT) kernel: type 12 trap, code=0 CPU1 stopping CPUs: 0x00000001 stopped Stopped at slab_cleanup+0x1c9: cmpq %rbx,(%rcx) db> ---------------------------------------------------------------- [ Run 2 ] fresh boot (vm.sh reset -> clean-install) attach overflow.img + single trigger + 5-iter stress + 16-proc flood ---------------------------------------------------------------- The trigger returned nslices=130; the panic then fired during the parallel flood when fork1()->_kmalloc() walked into the overflow-corrupted zone and the slab allocator's own integrity check (KKASSERT) caught it: login: panic: slaballoc: corrupted zone cpuid = 1 Trace beginning at frame 0xfffff800abacb798 _kmalloc() at _kmalloc+0x95a 0xffffffff80656e2a _kmalloc() at _kmalloc+0x95a 0xffffffff80656e2a fork1() at fork1+0x9c9 0xffffffff806429c9 sys_fork() at sys_fork+0x33 0xffffffff80642c63 sys_xsyscall() at sys_xsyscall+0x89 0xffffffff80bd6749 syscall2() at syscall2+0x11e 0xffffffff80bd611e Debugger("panic") CPU1 stopping CPUs: 0x00000001 stopped Stopped at Debugger+0x7c: movb $0,0xbd77f9(%rip) db> ================================================================ INTERPRETATION ================================================================ - "nslices=130" returned to userspace proves the live kernel diskslices has dss_nslices=130, so the bcopy at subr_diskslice.c:557 copies 130*256+32 = 33312 B into the 4128-B data buffer -> 29184 B overrun, every single run. - "slaballoc: corrupted zone" is the slab allocator detecting the overrun (sys/kern/kern_slaballoc.c zone-consistency assertion). - The two different crash sites across two identical runs (slab_cleanup NULL deref vs. _kmalloc<-fork1 assertion) are both hallmarks of slab-metadata corruption and confirm the corruption source is the DIOCGSLICEINFO overflow. - The panic is asynchronous and probabilistic in exact site/timing (the overrun corrupts whatever slab object is adjacent at runtime), but the underlying heap overflow is 100% deterministic on every invocation. ---------------------------------------------------------------- [ Run 3 ] fresh boot (vm.sh reset -> clean-install) attach overflow.img + single trigger + 5-iter stress + 16-proc flood ---------------------------------------------------------------- The trigger returned nslices=130; this time the 28 KB overrun corrupted the ROOT disk's (vbd0s1d) slice metadata in kernel heap, producing dscheck "slice too large" errors and a downstream hammer2 filesystem assertion: dscheck(vbd0s1d): slice too large 2/0 hammer2: chain error during flush hammer2: WRITE PATH: dbp bread error xop_strategy_write: error 22 loff=0000000000000000 panic: assertion "parent->error == 0" failed in hammer2_chain_create at /usr/src/sys/vfs/hammer2/hammer2_chain.c:3112 cpuid = 1 Trace beginning at frame 0xfffff800682935f0 hammer2_chain_create() at hammer2_chain_create+0x1209 0xffffffff80973509 hammer2_chain_create() at hammer2_chain_create+0x1209 0xffffffff80973509 hammer2_assign_physical() at hammer2_assign_physical+0x209 0xffffffff80983069 hammer2_xop_strategy_write() at hammer2_xop_strategy_write+0x681 0xffffffff80984a41 hammer2_primary_xops_thread() at hammer2_primary_xops_thread+0x280 0xffffffff8095d140 Debugger("panic") CPU1 stopping CPUs: 0x00000001 stopped Stopped at Debugger+0x7c: movb $0,0xbd77f9(%rip) db> (Note: this panic is in the ROOT filesystem's driver, NOT in the crafted vn0 disk -- proof that the overrun corrupts arbitrary adjacent kernel heap, here the live diskslices/slab objects describing vbd0. Three fresh-boot runs, three different crash sites, one root cause: the DIOCGSLICEINFO 28 KB heap overflow at subr_diskslice.c:557.)