DF-5470 — DDB backtracer frame walk trusts stack content as frame pointers (INKERNEL() defined, never used); walk escapes into user/mapped/unmapped memory

File: sys/platform/pc64/x86_64/db_trace.c (pass 2) Severity: Medium · Bucket: base:ddb / anti-forensics Status: REPRODUCED on stock guest (see run.log, leak_flood_sample.txt)

What

db_stack_trace_cmd()/db_nextframe() walk the frame-pointer chain with a single sanity check — (unsigned long)*fp < PAGE_SIZE (db_trace.c:227). The file defines INKERNEL(va) at db_trace.c:131 and never uses it — the kernel-space validation that the ancestor FreeBSD code performs was dropped in the x86-64 port. Adopted frames (rbp read from stack/memory content) can therefore be:

• user-space addresses (the panicking/traced process's own mappings are live during panic and DDB traces), or
• arbitrary mapped kernel addresses (heap, other stacks), or
• unmapped addresses (→ fault inside db_read_bytes, see DF-5471).

The convenience scan for trace <addr> (db_trace.c:336-352) likewise reads 8-byte words at addr..addr+4088 with no validation of addr.

Proof (this pack)

A KLD harness (src/df_trace_harness.c) calls the production db_stack_trace_cmd() from a live syscall context. An unprivileged user (uid 1001, src/user_chain.c) sprays 40000 fake frames in its own address space at 0x60000000; the walk runs in that process's context (identical to the context of a panic inside the attacker's syscall — print_backtrace() runs on the panicking thread with its page table active):

• 30000 frames walked through user memory, one msgbuf line each;
• 22754+ lines (~1.07MB ≥ MSGBUF_SIZE=1MB) flood the message buffer;
• the walk's own start line and the entire pre-existing msgbuf content (boot context; on a real system: the panic message, trap registers, and the useful head of the backtrace) are evicted — forensic evidence destroyed, output fully attacker-steered.

fix.diff restores the check: frames must satisfy INKERNEL() and move strictly up the stack; trace <addr> refuses non-kernel addresses. Verified on a rebuilt kernel: the user-VA walk is refused ("0x60000000 is not in kernel space"), zero flood lines, msgbuf intact.

Build / run

./build.sh          # push src/ to guest, build KLD + user_chain, load
./run.sh            # baseline sequence with expected outputs inline

Requires the dfbsd-qemu guest (stock X86_64_GENERIC: DDB, DDB_TRACE, INVARIANTS). For the fix validation: apply fix.diff in the guest /usr/src, make nativekernel KERNCONF=X86_64_GENERIC && make installkernel, reboot, re-run run.sh.

DF-5470 VERDICT — REPRODUCED (impact: dos / anti-forensics)

Result

Why it is real

• INKERNEL() is defined at sys/platform/pc64/x86_64/db_trace.c:131 and referenced nowhere in the file — the kernel-space validation of the ancestor code was dropped in the x86-64 port.
• The only frame validation in the walk is (unsigned long)*fp < PAGE_SIZE (db_trace.c:227). db_nextframe() adopts whatever 64-bit value sits at [rbp] as the next frame (db_trace.c:232,258) — user addresses, mapped kernel heap, cycles, or unmapped VA all pass.
• During a panic or DDB trace on a thread whose process has user mappings, user VA is directly readable by the walk: the panic-time print_backtrace() (stock DDB_TRACE, kern_shutdown.c:880-881) runs on the panicking thread with its page table still active. An attacker whose syscall panics the kernel (user-triggerable panics exist independently) fully controls every subsequent "frame": its f_retaddr (printed), and via the calltrap/Xresume*/_Xsyscall symbol-name heuristic (db_trace.c:240-251) the fake "trapframe" contents at fp+16 (db_trace.c:268-302) — printed as trapno/rip/rsp/rbp.
• Output goes to msgbuf: db_putchar() routes through kprintf() when db_active==0 (db_output.c:107-116) — true for the whole panic-time walk (db_active is only incremented later in kdb_trap).
• Demonstrated consequence: ~1MB of attacker-steered output evicts the real panic evidence from the 1MB msgbuf (run.log: pre-walk boot lines and the walk's own start line both gone). This is the anti-forensics amplifier of the already-reported address exposure DF-1077 (not re-reported here); it is also the enabling half of DF-5471 (unmapped-VA adoption → db_read_bytes fault → longjmp hazard).

Honest scope notes

• The walk itself performs no writes; there is no memory-corruption primitive in this finding, hence no uid0 chain. The demonstrated impact is denial-of-service of forensic data (msgbuf eviction) plus attacker-steered kernel output. The crash consequence of the same missing validation is DF-5471.
• The harness trigger is an instrumentation sysctl (root-loadable KLD) standing in for the kernel's own invocation sites (panic()/DDB). The unprivileged-reachability claim rests on (a) user-triggerable panics existing elsewhere in the kernel and (b) the walk running in the attacker's address-space context — both cited; the walk mechanics demonstrated are the production code path (db_stack_trace_cmd + db_nextframe unmodified).
• db_numargs() returns 0 (db_trace.c:166) and X_db_sym_numargs() is hard-wired FALSE (db_kld.c:107-111), so the argnames[MAXNARG] stack-array path is dead on this platform — no overflow there.

Fix

fix.diff (git-apply-able, validated): frames must be INKERNEL() and strictly forward; trace <addr> refuses non-kernel addresses. Same diff fixes DF-5471's trigger from the walk side.

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.