DragonFlyBSD Kernel Audit
DF-0812 / panic.txt
← back to finding ↓ download raw
=== DF-0812 PANIC: Fatal trap 12 in memmove during HAMMER REDO recovery ===
=== Captured from dfbsd-qemu/boot.log on kernel #0 (GENERIC, INVARIANTS ON) ===

HAMMER(TEST) recovery check seqno=0010028e
HAMMER(TEST) recovery range 300000000004b548-300000000004cf48
HAMMER(TEST) recovery nexto 300000000004cf48 endseqno=001002af
HAMMER(TEST) recovery undo  300000000004b548-300000000004cf48 (6656 bytes)(RW)
HAMMER(TEST) Found REDO_SYNC 3000000000000000
HAMMER(TEST) recovery complete
HAMMER(TEST) recovery redo  300000000004b548-300000000004cf48 (6656 bytes)(RW)
HAMMER(TEST) Find extended redo  3000000000000000, 308552 extbytes

Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic id = 0
fault virtual address	= 0xfffff8007657a000
fault code		= supervisor read data, page not present
instruction pointer	= 0x8:0xffffffff80bcaa0a
stack pointer	        = 0x10:0xfffff80117a86f90
frame pointer	        = 0x10:0xfffff80117a86fe8
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 964
current thread          = pri 10 
kernel: type 12 trap, code=0

CPU0 stopping CPUs: 0x0000003e
 stopped
Stopped at      memmove+0x10a:  repe movsq      (%rsi),%es:(%rdi)
db> 

=== Analysis ===
The panic occurs in memmove (the bcopy implementation) during stage-2 REDO
recovery. hammer_recover_redo_exec() called vn_rdwr(UIO_WRITE, vp,
(void*)(redo+1), redo->redo_data_bytes, ...) with the forged
redo_data_bytes=0x7FFFFFFF. The memmove's repe movsq instruction reads
sequentially from (%rsi) = (redo+1) until it hits the unmapped page at
0xfffff8007657a000, triggering the page fault.

This confirms: unvalidated redo_data_bytes causes an OOB kernel heap read
that walks into unmapped memory → fatal trap 12.