DF-5728 — DDB db_expression unbounded '(' recursion overflows the 16 KB kernel stack

What

sys/ddb/db_expr.c has no recursion-depth limit. Each ( token drives six nested frames (db_term → db_expression → db_shift_expr → db_add_expr → db_mult_expr → db_unary, back into db_term). Measured on the guest's X86_64_GENERIC kernel: 272 bytes of kernel stack per nesting level (db_term 32 + db_expression 16 + db_shift_expr 64 + db_add_expr 64 + db_mult_expr 64 + db_unary 32).

DDB runs on the interrupted context's kernel stack (UPAGES=4 → 16 KB, with a guard page). The ddb input line buffer is 120 bytes (sys/ddb/db_lex.c:42), so a single console line of (s requests up to 120 levels = ~32.6 KB of recursion — twice the stack. The 16 KB guard page catches it: double fault → panic: double fault → crashdump.

Trigger line (typed at a db> prompt):

p (((((((((((((((((((((((((((((((((((((((((((1     <- 60 '(' = 16.3 KB: fatal

Empirical threshold varies with the interrupted context's remaining stack: run 1 (sysctl/thread-context entry) survived 30 levels (8.2 KB) and died at 60; run 2 died at 40 — during the db_error("Syntax error") print at depth (db_printf → db_force_whitespace), i.e. the error path at depth needs headroom too. Two independent boots, 2/2 panics.

Files

• serial_vm.sh — boots the guest with a writable socket serial console (same disk/kvm/pidfile as dfbsd-qemu/vm.sh)
• drive_ddb.py — paced serial driver (8-byte chunks, UART FIFO limits)
• run1-fullserial.log — full chardev log, run 1: sanity + 30 survives + 60 → DOUBLE FAULT
• run1-panic60.serial.raw — driver-side capture of the same session
• run2-sweep.serial.log — run 2: first bomb (40) → DOUBLE FAULT (rip db_force_whitespace+0xc)
• run3-controls.serial.log — controls on stock kernel: p (1+(2*3))=7, balanced-20 nesting=1, 117-frame unary chain=-1, clean c exit
• fix.diff — DB_MAX_EXPR_DEPTH=16 cap (+ reset in db_flush_lex)
• build.log — patched kernel build (nativekernel) + install
• postfix-run.log — patched kernel: same bombs, no panic
• panic.txt — the fatal double-fault frames from both runs

Reproduce (baseline panic)

1. ./serial_vm.sh up (or vm.sh reset with-src, then this rig)
2. dfbsd-qemu/vm.sh run_root 'sysctl debug.enter_debugger=ddb' & — enters DDB on the serial console (thread-context entry, the clean-exit class)
3. DF5728_SOCK=/tmp/opencode/df-5728-ser.sock ./drive_ddb.py "$(python3 -c 'print("p "+"("*60+"1")')" 8
4. Expected: DOUBLE FAULT - KERNEL STACK GUARD HIT! / panic: double fault, crashdump, host-side guest unresponsive (serial shows panic frames).

Success criterion

Kernel panic (panic: double fault, rsp page-aligned on the kstack guard page) from a single DDB console line. With fix.diff: the same input yields Expression too deep and the session continues — no panic.

Threat model

Anyone with write access to the (serial) console of a system where debug.enter_debugger-style DDB entry or break-to-debugger is available: serial-terminal servers, IPMI/SoC serial, hypervisor console pipes. Same actor class as the other DDB findings (DF-2238/2239/2241): console access is treated as privileged-adjacent (PR:H) → Low severity, availability-only.

DF-5728 VERDICT — REPRODUCED (panic/dos, 2/2 boots) + fix validated

Root cause (source-traced)

• sys/ddb/db_expr.c:84-95 — db_term()'s tLPAREN branch calls db_expression() with no depth limit: c if (t == tLPAREN) { if (!db_expression(valuep)) { /* recursion */
• db_expression → db_shift_expr → db_add_expr → db_mult_expr → db_unary (db_expr.c:225-229,193-223,165-191,127-163) → back into db_term — six frames per (.
• Input length is capped only by db_line[120] (sys/ddb/db_lex.c:42), i.e. up to ~118 consecutive ( after a command word (p).
• DDB executes on the interrupted context's kernel stack: x86_64 UPAGES=4 → 16 KB with a guard page (sys/cpu/x86_64/include/param.h).
• Measured frames from the guest kernel (objdump -d /boot/kernel/kernel): db_term 32 B (2 push+sub8+ret), db_expression 16 B, db_shift_expr 64 B (5 push+sub16+ret), db_add_expr 64 B, db_mult_expr 64 B, db_unary 32 B → 272 B per nesting level. 60 levels = 16.3 KB ≥ the whole stack; 120 levels = 32.6 KB.

Reproduction (live, socket-serial DDB rig)

Rig: serial_vm.sh (QEMU chardev socket serial, same disk as vm.sh) + drive_ddb.py (paced 8-byte sends). DDB entered via root sysctl debug.enter_debugger=ddb (sys/ddb/db_sysctl.c:75) — the thread-context entry class exonerated for clean exit by DF-5722's controls.

• Run 1 (run1-fullserial.log, run1-panic60.serial.raw):
• p (1+(2*3)) → 7 (sanity, evaluator healthy)
• p + (×30 + 1 → Syntax error, db> returns (survives: 8.2 KB)
• p + (×60 + 1 → DOUBLE FAULT - KERNEL STACK GUARD HIT! Fatal double fault rip = 0xffffffff802ca73c <- db_unary+0xc (pure descent) rsp = 0xfffff801184cf000 <- page-aligned: kstack guard page panic: double fault → 570 MB crashdump, guest dead.
• Run 2 (run2-sweep.serial.log, fresh boot): first bomb (×40 → descent survived (10.9 KB < free stack) but the unwind's db_error("Syntax error") → db_printf → db_force_whitespace at depth crossed the guard: rip = 0xffffffff802cba0c <- db_force_whitespace+0xc rsp = 0xfffff80117e77000 <- page-aligned guard page panic: double fault → second crashdump, 2/2 boots.
• Run 3 (run3-controls.serial.log, stock kernel, no bomb): balanced nesting depth 20 evaluates (1), a 117-frame unary chain (-----…-1) evaluates (ffffffffffffffff = -1, ~2.9 KB — unary chains alone are NOT fatal), and c exits DDB cleanly. (The guest then soft-wedged post-exit — the DF-5722 DDB-exit fragility family, unrelated to this finding; evidence was already captured and the box was reset.)

Threshold variance (30 ok/60 dead in run 1; 40 dead in run 2) is explained by the interrupted thread's remaining stack at DDB entry — both bounds are far below the 118-level maximum the lexer accepts, so the bug is deterministically triggerable at p + (×118.

Note: crashdumps from runs 1/2 were written to the pre-revert disk state and discarded by the with-src snapshot reverts; the serial logs above carry the complete fatal frames (rip/rsp/trace), which is the evidence of record.

Impact classification

panic / DoS. The guard page converts the overflow into a clean double fault + panic + dump (no silent adjacent-kernel-memory corruption was observed; x86_64 DFly kstacks are guard-paged on this kernel). Reachable from the DDB console only — same privileged-adjacent actor as DF-2238/ 2239/2241 → Low severity, availability-only. Not an escalation path: the console actor can already call/write/reset by DDB design.

Fix validation (mandatory for reproduced memory-corruption-class bugs)

fix.diff caps nesting at DB_MAX_EXPR_DEPTH 16 (≈4.4 KB worst-case recursion) in db_expression(), and resets db_expr_depth in db_flush_lex() (sys/ddb/db_lex.c) because db_error() longjmps (sys/ddb/db_command.c:486) past the decrement on every abort path — db_flush_lex() is called by db_error() itself, so the counter cannot go stale. The db_unary '-'/'*' self-recursion is NOT capped: bounded by the 120-char line to ~119 × 24-32 B ≈ 3.8 KB worst case (control run 3 confirms survival at 117 frames).

Built with make nativekernel KERNCONF=X86_64_GENERIC in the guest (build.log), installed, rebooted, and re-driven with the identical rig:

• baseline (stock kernel): p + (×40/×60 → double fault (runs 1-2)
• patched kernel (postfix-run.log): p + (×60 and (×118 → Expression too deep, db> returns, no panic; sane controls (p (1+(2*3)) → 7; balanced-8 nesting evaluates; unary chain = -1). Usability tradeoff documented: balanced nesting deeper than 16 now errors instead of evaluating (legal-but-pathological input).

fix_status: fixed (baseline reproduced, patched not reproduced).

Not-a-bug notes from the same trace

• db_term's other recursions (*/- unary, db_expr.c:106-121) are single-frame-per-char chains — bounded ≤ ~3.8 KB by the line length.
• Divide-by-zero is guarded (db_expr.c:147-150); signed /-1 #DE and the 32-bit shift truncation are DF-2241/DF-2242 (not re-reported).
• Faults on bad *addr derefs in DDB land in trap_fatal→kdb_trap (sys/platform/pc64/x86_64/trap.c:420,1096) — the known DF-2241 wedge family, not re-reported.

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.