DF-5472 — vkernel64 backtracer frame walk trusts stack content; INKERNEL() dead AND semantically wrong for the platform; walk escapes into guest-user VAs and attacker-chosen kernel symbols are printed (pc64 DF-5470 twin, with vkernel-specific amplification)

File: sys/platform/vkernel64/x86_64/db_trace.c (pass 2) Severity: Medium · Confidence: certain · Verified: reproduced on the QEMU guest (in-vkernel rig)

What

Identical defect class to the pc64 twin (DF-5470), plus two vkernel-specific aggravations:

1. INKERNEL(va) is defined at db_trace.c:132 and never referenced. The only validation of an adopted frame pointer is (unsigned long)*fp < PAGE_SIZE (db_trace.c:227). Whatever QWORD sits at [rbp] becomes the next frame and is dereferenced (db_trace.c:231-232), and the "trapframe" heuristic reads *fp+16 with a raw deref (db_trace.c:268).
2. Even if INKERNEL() were wired in, the inherited definition is wrong for the vkernel: INKERNEL(va) = va >= USRSTACK with USRSTACK = VM_MAX_USER_ADDRESS ≈ 0x7FFF_FFFF_F000 (vmparam.h:94,100) — but the vkernel's kernel lives at KERNEL_KVA_START = 512GB .. +512GB (vmparam.h:80-81), i.e. inside [0, USRSTACK). The inherited test would reject every real kernel frame and accept most guest-user addresses. The correct bound is [KvaStart, KvaEnd) (platform/init.c:609-621, vm/pmap.h:141). The tree's generic helper kva_p() (vm/pmap.h:162-171) is also useless here: for _KERNEL_VIRTUAL it is hardcoded addr != NULL.
3. The trap/syscall/interrupt frame heuristics (calltrap, Xresume*, _Xsyscall, db_trace.c:244-248) are dead code on vkernel64 — those symbols do not exist anywhere in the platform (traps arrive as host signals via exc_segfault → kern_trap, exception.c:263, trap.c:583). The walk structurally cannot recognize a kernel↔user boundary.

Vkernel-specific impact (guest-proven)

Guest-user memory of the process whose syscall is being traced lives in a different host vmspace than the vkernel kernel: vkernel copyin (platform/copyio.c:311-322) never raw-dereferences a user VA (it uses vm_fault_page + kernel-window lwbuf copies). Consequently, unlike pc64 where the escaped walk reads user memory, on vkernel64 any adopted guest-user frame pointer guarantees a fault in db_read_bytes — which falls into the broken no-fault recovery (DF-5473) and destroys the vkernel process with zero further diagnostics. Values that do stay in kernel KVA are fully attacker-steerable: the trace prints the symbol of any kernel address the corrupted stack happens to hold (kprintf() at 0x50d850 printed from a rig-chosen return address in the clean run), and raw hex for the rest (the leak aspect is DF-1078's; the steering + escape + guaranteed fault is this finding).

Proof (this pack)

In-vkernel rig: a VKERNEL64 kernel (built on the guest, plus rig harness vk_trace_harness.c) boots on a minimal UFS image; an ordinary guest process (vktrigger) sprays a fake frame chain at guest-user VA 0x100000000 and asks the harness to walk a kernel chain whose second frame points there (db_stack_trace_cmd(chain, TRUE, 6, NULL) — the exact entry print_backtrace() uses, db_trace.c:449 — from live syscall context with db_active == 0, the panic-path state).

• vkrun_clean.log — control: chain stays in kernel KVA; walk completes, prints rig-chosen symbols, returns; vkernel survives.
• vkrun_bad.log — walk adopts 0x100000000: Fatal trap 12: page fault, fault virtual address = 0x100000008 (= the f_retaddr read at db_trace.c:231) in process vktrigger, then the DF-5473 cascade.
• vkrun_fixed.log — with fix.diff (KvaStart/KvaEnd walk validation + forward-progress check) the same trigger stops cleanly at the boundary, "DFVK: walk RETURNED without crashing", vkernel survives.

Fix

fix.diff (shared with DF-5473): redefine INKERNEL to [KvaStart, KvaEnd), reject non-kernel/non-forward frames at every adoption point (db_nextframe entry :227, NORMAL path :256, trap epilogue :308, have_addr entry :335). Validated: bad trigger returns cleanly, no crash, vkernel stays up (vkrun_fixed.log).

Build / run

See DF-5473 pack (build_image.sh, run_vk.sh); sources in src/.

DF-5472 VERDICT — reproduced (in-vkernel rig)

Bottom line: The vkernel64 backtracer adopts arbitrary 64-bit frame pointers from stack content. INKERNEL() (db_trace.c:132) is never called, and — a pass-2 discovery — it is semantically wrong for this platform anyway (kernel KVA 512GB..1TB lies inside [0, USRSTACK≈128TB); vmparam.h:80,94,100). On vkernel, guest-user memory lives in a separate host vmspace (platform/copyio.c:311 never raw-derefs user VA), so any adopted guest-user frame guarantees a fault in db_read_bytes — the walk does not merely read attacker memory like pc64 (DF-5470), it detonates the broken no-fault path (DF-5473). Kernel-KVA values remaining in the chain are fully steerable: the clean run prints the rig-chosen symbol (kprintf() at 0x50d850) — an unprivileged guest process corrupting its own stack content (or any kernel stack corruption) chooses which "functions" appear in the panic trace.

How reproduced (2 deliberate runs + 1 accidental, fresh boots each)

• rig: guest-built VKERNEL64 kernel + in-kernel harness (debug.df_vk_walk sysctl runs db_stack_trace_cmd(chain, TRUE, 6, NULL) — the exact entry of print_backtrace(), db_trace.c:443-450 — from live syscall context, db_active=0, db_jmpbuf all-zero, verified in the log line DFVK: db_active=0 db_jmpbuf[0]=0000000000000000 db_jmpbuf[3]=0000000000000000).
• vkrun_clean.log: chain kept in kernel KVA → 2×(null)() at 0x8002037030
• kprintf() at 0x50d850 (rig-chosen return address symbolized), walk returned, vkernel survived (VK_EXIT=0).
• vkrun_bad.log: chain points into guest-user VA 0x100000000 (mapped for the guest process — vtrigger's mmap succeeded — but not dereferenceable from kernel context) → Fatal trap 12: page fault, fault virtual address = 0x100000008 — the f_retaddr read at db_trace.c:231 (faulting insn verified in the disassembly: 0x71ca40: movzbl (%rdi),%ecx, the db_read_bytes copy loop, db_interface.c:239-240) → DF-5473 cascade kills the vkernel (signal 4, core dumped).

Exploit chain

Not a host-privesc class: the vkernel is an unprivileged host process; impact is inside the vkernel's own threat model (steered/destroyed panic forensics, kernel-process death from a live debug-print site). Chain: guest process influences stack content walked during a vkernel panic/debug-print → walk escapes kernel KVA → guaranteed SIGSEGV → broken no-fault longjmp → vkernel process destroyed with zero diagnostics (anti-forensics amplifier).

Fix validation

fix.diff (in DF-5473 pack, shared): INKERNEL → [KvaStart,KvaEnd), frame adoption validated at db_trace.c:227/256/308 + have_addr entry :335. Rebuilt vkernel, identical bad trigger → 2 frames printed, walk stops at the guest-user boundary, DFVK: walk RETURNED without crashing, sysctl returned, clean halt, no signal-4 death (vkrun_fixed.log, guest dmesg clean). fix_status: fixed.

Negative results (classes hunted, killed)

• db_sym_numargs/argnames OOB (db_trace.c:421-426): DEAD — vkernel uses db_kld.c:107 X_db_sym_numargs which is hardcoded return FALSE; narg comes from db_numargs() which returns 0 (db_trace.c:163-167).
• trapframe heuristics (db_trace.c:244-248): dead code — calltrap, Xresume*, _Xsyscall exist nowhere in vkernel64 (signal-based traps); contributes to the boundary-blindness covered by this finding.
• watchpoint paths (kx86_64_set_watch etc., db_trace.c:473-652): DDB-console only (operator), not attacker-reachable.
• dl_symbol_values/host dladdr() on garbage callpc (db_trace.c:659-669): dladdr walks link_map ranges without dereferencing callpc — no memory safety issue found.
• db_numargs instruction-decode OOB read: disabled at db_trace.c:166 (#if 1 return 0).

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)