DF-5471 — backtrace fault outside a DDB session longjmps into uninitialized/stale global db_jmpbuf → double fault → panic

File: sys/platform/pc64/x86_64/db_trace.c (pass 2, cross-file with db_interface.c, db_command.c) Severity: Medium · Bucket: base:ddb / DoS-amplification Status: REPRODUCED on stock guest (twice), crash signature in panic.txt

What

Every dereference the backtracer performs goes through db_get_value() → db_read_bytes(), which arms the global no-fault recovery db_nofault = &db_jmpbuf (db_interface.c:242) around a raw pointer dereference. On a fault, kdb_trap() executes longjmp(*no_fault, 1) (db_interface.c:140-143).

db_jmpbuf (db_command.c:62, BSS-zeroed) is only initialized by setjmp() at db_command.c:467 / db_trap.c:68 — i.e. inside an established DDB session. But db_stack_trace_cmd() also runs:

1. On every panic, before DDB exists — stock X86_64_GENERIC has options DDB_TRACE, so trace_on_panic=1 and panic() (kern_shutdown.c:880-881) calls print_backtrace(6) before Debugger("panic") ever runs setjmp(db_jmpbuf).
2. From live kernel debug sites with no debugger involved, e.g. m_copyback() failure (uipc_mbuf.c:2413, unguarded) and mfree() anomaly printing (uipc_mbuf.c:1339, unguarded), plus INVARIANTS lock_test_mode sites (kern_lock.c:389, indefinite2.h:116 — INVARIANTS is in the stock config).

If the walk adopts a garbage frame pointer (precisely what happens when the panic was caused by stack/memory corruption — the moment you need the dump most) and dereferences an unmapped page:

#PF in db_read_bytes
  → trap_pfault → trap_fatal (trap.c:1096, debugger_on_panic=1 default)
  → kdb_trap: db_nofault armed → longjmp(db_jmpbuf)
  → db_jmpbuf all-zero (or stale from a previous DDB session on another
    thread/stack) → longjmp restores rsp=0, rbp=0, rip=0
    (support.s:802-814; first faulting insn is the write `movq %rdx,0(%rsp)`
     at support.s:811 with rsp=0)
  → DOUBLE FAULT → dblfault_handler → panic("double fault")

The original panic's dump/forensics are destroyed or hopelessly interleaved; a live debug print site becomes a full system crash.

Proof (this pack)

KLD harness: sysctl -w debug.df_kfault=1 walks a kmalloc'd chain whose 2nd frame pointer is 0xffffdead00000000 (unmapped kernel VA), from live syscall context, on a fresh boot (db_jmpbuf zeroed — same state as the panic path). Observed on serial (panic.txt): Fatal trap 12 at 0xffffdead00000008 (the f_retaddr read, db_trace.c:231) → kernel: type 12 trap → Fatal double fault: rip=0xffffffff80bcb71f (longjmp), rsp=0x0, rbp=0x0 → panic: double fault → auto-trace → DDB wedge, guest down. Reproduced twice.

fix.diff (shared with DF-5470) makes the walk refuse out-of-kernel-space and non-forward frames, so db_read_bytes is never pointed at the unmapped VA from the walk. Verified on a rebuilt kernel: the same trigger prints two valid frames and returns cleanly — DFTRACE: kfault: walk returned without crashing, zero panic lines, guest stays up (run.log, fix_validation.txt).

Complete remediation additionally needs a db_interface.c change (arm a jmpbuf that is valid whenever db_nofault can fire, e.g. setjmp a local buffer in print_backtrace()/db_stack_trace_cmd() entry, or make kdb_trap fall back to db_global_jmpbuf when the DDB loop never ran) — out of this file's scope, noted in the finding's recommended fix.

Build / run

./build.sh          # push src/ to guest, build KLD + user_chain, load
./run.sh            # kfault trigger; CRASHES the stock guest (by design)

DF-5471 VERDICT — REPRODUCED (impact: panic — deterministic crash from the backtrace fault path; forensic destruction)

Result

Mechanism (all source-cited)

1. db_stack_trace_cmd() → db_nextframe() adopts garbage rbp (0xffffdead00000000) — only guard is < PAGE_SIZE (db_trace.c:227) — and reads (*fp)->f_retaddr (db_trace.c:231).
2. db_get_value() → db_read_bytes() arms db_nofault = &db_jmpbuf (db_interface.c:242) and dereferences (db_interface.c:244-246).
3. #PF → kernel-mode fault → trap_fatal() (trap.c:1019) → (debugger_on_panic || db_active) && kdb_trap(...) (trap.c:1096; debugger_on_panic=1 by default, kern_shutdown.c:110).
4. kdb_trap() default case sees armed db_nofault → longjmp(*no_fault, 1) (db_interface.c:140-143) = longjmp(db_jmpbuf).
5. db_jmpbuf is BSS (db_command.c:62), set ONLY by setjmp inside an established DDB session (db_command.c:467, db_trap.c:68). On a fresh boot it is all zeros — exactly the state of the stock panic path, where print_backtrace(6) (kern_shutdown.c:880-881; trace_on_panic=1 because options DDB_TRACE is in X86_64_GENERIC) runs BEFORE Debugger("panic"). Also the state at every unguarded live debug site (uipc_mbuf.c:2413 m_copyback, uipc_mbuf.c:1339 mfree; INVARIANTS sites kern_lock.c:389 / indefinite2.h:116).
6. longjmp restores rsp=0/rbp=0/rip-from-zeroed (support.s:803-810); the very next instruction movq %rdx,0(%rsp) (support.s:811) writes to VA 0 → #DF. Serial confirms: rip=0xffffffff80bcb71f (inside longjmp), rsp=0x0, rbp=0x0.
7. dblfault_handler() (trap.c:1125) → panic("double fault") → nested-panic path → DDB wedge. The original panic context (or, on the live-path variant, a merely-diagnostic warning) is destroyed; no clean dump of the original event.

Narrative honesty / deviations

• Trigger is a harness sysctl standing in for the kernel's own invocation of the same walk (print_backtrace/ddb trace); the exercised code (db_stack_trace_cmd + db_nextframe + db_read_bytes + kdb_trap + longjmp) is stock, unmodified.
• "Run 2": the fix-validation cycle initially failed to reboot the guest (my && chain aborted on a kenv non-zero exit), so the "patched" run in fact executed the stock kernel again — producing a second, independent baseline crash with an identical signature before the true patched run. Both are documented in run.log; the true patched run followed after a forced power cycle (uname confirmed #1 Oct 6 01:12:20, fix string present in /boot/kernel/kernel).
• The stale-jmpbuf variant (DDB entered and exited earlier in the boot; db_jmpbuf then holds a dead db_command_loop context on a possibly reused kernel stack → longjmp resumes a ghost frame in arbitrary thread context) is real by the same code path but was not separately demonstrated; the zeroed variant is deterministic and fully proven.
• No attacker-controlled register restore is available in the zeroed variant (BSS is not attacker-writable), so there is no uid0 chain from this primitive alone; impact is crash/DoS + forensic destruction.

Fix

fix.diff (shared with DF-5470) prevents the walk from adopting out-of-kernel-space / non-forward frames, eliminating the demonstrated trigger from the trace side (validated: crash gone). Complete remediation should additionally make the no-fault recovery safe in db_interface.c (e.g. a setjmp'd local buffer established by print_backtrace()/db_stack_trace_cmd() before any db_get_value, or a validity flag for db_jmpbuf checked in kdb_trap), since other DDB read paths can fault outside a DDB session too.

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.