# DF-5473 VERDICT — reproduced (in-vkernel rig, twice + 1 accidental)

**Bottom line:** A fault taken by the vkernel backtracer outside an
established DDB session longjmps into the never-initialized global
`db_jmpbuf` (sys/ddb/db_command.c:62) — because `db_read_bytes` arms
`db_nofault = &db_jmpbuf` (vkernel db_interface.c:236) but the buffer is only
`setjmp`'d inside `db_command_loop` (db_command.c:467) / `db_trap`
(db_trap.c:68). On the vkernel the longjmp is **host libc's**, run from
inside a signal handler, into a BSS-zeroed buffer: it restores rsp=0/rbp=0
and the process dies of SIGILL inside libc `longjmp+115` (core-dumped) —
destroying the vkernel, the panic backtrace it was printing, and any chance
of DDB. State proven identical to the panic path: `db_active=0`,
`db_jmpbuf` zeroed (harness print), which is exactly the state during
`print_backtrace(6)` at kern_shutdown.c:881 (runs BEFORE `Debugger("panic")`)
and during every live `print_backtrace(-1)` debug site.

## Evidence chain (all files in this pack)

1. `vkrun_bad.log` (also in DF-5472 pack): walk adopts guest-user VA →
   ```
   Fatal trap 12: page fault while in kernel mode
   fault virtual address = 0x100000008        <- db_trace.c:231 f_retaddr read
   instruction pointer = 0x2b:0x71ca40        <- movzbl (%rdi),%ecx = db_read_bytes
                                                  copy loop (db_interface.c:239-240)
   current process = 3 (vktrigger)            <- live syscall context, not DDB
   kernel: type 12 trap, code=0               <- kdb_trap print (db_interface.c:136),
                                                  immediately before the longjmp
   <log ends — line 54 of 54>
   ```
   Nothing further is ever printed: no DDB prompt, no second Fatal trap, no
   reboot.
2. Guest host dmesg: `pid (kernel.stripped), uid 0: exited on signal 4 (core
   dumped)` (two entries: accidental + deliberate runs).
3. `core_gdb.txt` + first-session symbolization (binary matching at crash
   time): `#0 0x102903f3 in longjmp () from /lib/libc.so.8`, `rip
   0x102903f3 <longjmp+115>`, `rsp 0x0`, `rbp 0x0`, `Cannot access memory at
   address 0x0`. (The regenerated core_gdb.txt against the rebuilt binary
   shows the same rip=0x102903f3, signal 4; the guest's libc is stripped so
   the symbol came from the matching-build session.)
4. Isolated mechanism check on the guest: `longjmp` on a memset-0 jmp_buf →
   SIGSEGV exit 139 (ljtest) — inside the vkernel's signal-handler context
   the same restore dies as SIGILL at longjmp+115.
5. `vkrun_clean.log`: identical rig with the chain kept in kernel KVA — walk
   completes and returns; the vkernel survives. (The crash is caused by the
   out-of-DDB fault recovery, not by the walk harness itself.)

## Exploit chain

No host privilege escalation (vkernel = unprivileged host process). In-vkernel
impact: any vkernel panic whose frame chain is corrupted (the moment the
backtrace is needed most), or any live `print_backtrace()` debug site
(uipc_mbuf.c:1339, kern_jail.c:785, indefinite2.h:173, ...) hitting an
unmapped frame, converts a survivable diagnostic print into the death of the
kernel process with total loss of forensic output.

## Fix validation

The walk-side `fix.diff` (KvaStart/KvaEnd + forward-progress validation in
db_trace.c, shared with DF-5472) removes the demonstrated trigger: identical
bad run prints two frames, `DFVK: walk RETURNED without crashing`, clean halt
(`vkrun_fixed.log`). fix_status: fixed (walk-side); the complete remediation
additionally requires db_interface.c to arm a jmp_buf valid whenever
db_nofault can fire (e.g. setjmp a local in print_backtrace()/db_stack_trace_cmd()
entry, or fall back to db_global_jmpbuf when no DDB loop has run) — flagged
as out-of-this-file scope, mirroring pc64 DF-5471's note.

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.