DF-5473 — vkernel64 backtrace fault outside a DDB session longjmps into the BSS-zeroed global db_jmpbuf → libc longjmp restores rsp=0/rbp=0 → vkernel process dies of SIGILL inside longjmp (pc64 DF-5471 twin, vkernel flavor)

File: sys/platform/vkernel64/x86_64/db_trace.c (pass 2; mechanism spans sys/platform/vkernel64/x86_64/db_interface.c, sys/ddb/db_command.c) Severity: Medium · Confidence: certain · Verified: reproduced on the QEMU guest (in-vkernel rig), twice

What

Every dereference the vkernel backtracer performs goes through db_get_value() → db_read_bytes(), which arms the global no-fault recovery db_nofault = &db_jmpbuf (vkernel db_interface.c:236) around a raw pointer dereference. On a fault, the vkernel signal path (exc_segfault → kern_trap → trap_pfault → trap_fatal → kdb_trap, trap.c:959) executes longjmp(*no_fault, 1) (db_interface.c:138-142).

db_jmpbuf (sys/ddb/db_command.c:62, BSS-zeroed) is only initialized by setjmp() inside an established DDB session (db_command.c:467 db_command_loop, db_trap.c:68). But the vkernel runs the backtracer:

1. On every panic, before DDB exists — VKERNEL64 config has options DDB_TRACE (sys/config/VKERNEL64:59), so trace_on_panic=1 and panic() calls print_backtrace(6) (kern_shutdown.c:880-881) before Debugger("panic") — with db_jmpbuf still all-zero. The harness prints the state right before the walk: db_active=0 db_jmpbuf[0]=0 db_jmpbuf[3]=0.
2. From live kernel debug print sites with no debugger involved — the same unguarded print_backtrace(-1) sites as pc64 (uipc_mbuf.c:1339, kern_jail.c:785, indefinite2.h:173, busdma_machdep.c:205, ...).

The vkernel is a host userland process, so this longjmp/setjmp pair is host libc's, and the fault semantics differ from pc64 in the worst way: the fault arrives as an asynchronous host SIGSEGV inside libc's memcpy-ish loop in db_read_bytes, and the recovery longjmps out of a signal handler into a buffer that has never been set.

Observed crash chain (guest-proven)

db_stack_trace_cmd adopts guest-user VA 0x100000000 (DF-5472)
  → db_get_value/f_retaddr read (db_trace.c:231) faults
  → host SIGSEGV → exc_segfault (exception.c:263) → kern_trap (trap.c:583)
  → T_PAGEFLT → trap_pfault(FALSE) → vm_fault(kernel_map, 0x100000008) fails
  → trap_fatal (trap.c:887) → kdb_trap (trap.c:959)
  → prints "kernel: type 12 trap, code=0" (db_interface.c:136)
  → db_nofault armed → longjmp(db_jmpbuf, 1) on the ZEROED buffer
  → libc longjmp restores rsp=0, rbp=0 (rbx=0) → faults at longjmp+115
  → process killed by SIGILL: pid (kernel.stripped), uid 0: exited on
    signal 4 (core dumped)     [guest host dmesg]
  → core: #0 0x102903f3 <longjmp+115> in /lib/libc.so.8, rsp=0x0, rbp=0x0

After the longjmp the vkernel produces zero further output: no DDB prompt, no second "Fatal trap", no reboot — the original panic's evidence (the whole point of trace_on_panic) is annihilated and the process leaves an 11 MB core instead of a backtrace. Reproduced twice (accidental first run, then deliberate); the isolated mechanism was confirmed with a standalone longjmp-on-zeroed-jmp_buf test on the guest (exit 139, SIGSEGV — in the vkernel the surrounding context turns it into SIGILL inside libc longjmp).

Proof (this pack)

• vkrun_clean.log — control (chain stays in kernel KVA): walk completes, sysctl returns, vkernel survives (VK_EXIT=0, clean halt).
• vkrun_bad.log — the crash run: 54 lines, ends at kernel: type 12 trap, code=0; nothing after. Guest host dmesg: exited on signal 4 (core dumped). core_gdb.txt: #0 <longjmp+115> in /lib/libc.so.8, rsp=0x0, rbp=0x0.
• vkrun_fixed.log — with fix.diff (walk refuses non-kernel frames) the identical trigger prints two frames and returns; no fault, no signal, clean halt. The walk-side fix removes the reachable trigger; the full remediation additionally wants db_interface.c to arm a jmp_buf that is 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 ever ran) — noted as out-of-file scope.

Build / run

# on the guest (see README steps in full in run_vk.sh/build_image.sh):
sysctl -w vm.vkernel_enable=1
sh /root/vkrig/build_image.sh           # UFS root image with vktrigger
sh /root/vkrig/run_vk.sh clean          # control: survives
sh /root/vkrig/run_vk.sh bad            # crash: SIGILL in libc longjmp
sh /root/vkrig/run_vk.sh fixed          # after fix.diff: survives

The vkernel binary is make nativekernel KERNCONF=VKERNEL64 (requires the DF-5474 build fix first) with the rig harness sys/platform/vkernel64/x86_64/vk_trace_harness.c compiled in.

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.