DF-0780 — kernel panic signature (unpatched baseline, from dfbsd-qemu/boot.log) ============================================================================== Trigger: malicious FUSE daemon replies to FUSE_READ with 131072 bytes when the kernel requested 8192 (a 2-block cluster buffer). fuse_io_execute() does an unchecked memcpy of fuse_out_data_size() (131056 bytes) into bp->b_data (an 8192-byte buffer-cache buffer) => heap OOB write that runs off the end of the mapped buffer-cache KVA region and page-faults inside memcpy. panic: assertion "obj != NULL" failed in vm_object_hold_shared at /usr/src/sys/vm/vm_object.c:330 cpuid = 2 Trace beginning at frame 0xfffff80117f77638 vm_object_hold_shared() at vm_object_hold_shared+0x3f 0xffffffff809ab9bf vm_object_hold_shared() at vm_object_hold_shared+0x3f 0xffffffff809ab9bf vm_fault() at vm_fault+0x408 0xffffffff8099e0b8 trap_pfault() at trap_pfault+0x9a 0xffffffff80bd52ca trap() at trap+0x17c 0xffffffff80bd5bcc calltrap() at calltrap+0x9 0xffffffff80b991fa --- trap 000000000000000c, rip = ffffffff80bcac8a, rsp = fffff80117f77a50, rbp = fffff80117f77ab0 --- memcpy() at memcpy+0xfa 0xffffffff80bcac8a Debugger("panic") CPU2 stopping CPUs: 0x0000003b stopped Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip) db> Reproduced deterministically 3/3 runs from a fresh `vm.sh reset with-src` (unpatched audit-source kernel #0) + the stock fuse.ko built from the same source. Interpretation: * trap 0xc == T_PAGEFLT (12). The faulting RIP is inside memcpy() at memcpy+0xfa, i.e. the OOB *write* access in fuse_io_execute's memcpy(bp->b_data, fuse_out_data(fip), fuse_out_data_size(fip)); (sys/vfs/fuse/fuse_vnops.c:2054) ran past the end of bp->b_data's mapped KVA into an unmapped page. * vm_fault() tried to resolve the write fault, dereferenced a (corrupted / out-of-range) vm_object and hit the obj != NULL assertion. * The fault originates in the very memcpy that lacks the bound check, on the FUSE READ path, exactly as the finding describes.