# 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.)