DF-5475 — gdb_handle_exception spins forever when gdb_tab == NULL (RB_GDB with no gdb port): permanent all-CPU hang

sys/cpu/x86_64/misc/x86_64-gdbstub.c

What

getDebugChar() returns -1 when gdb_tab == NULL (sys/cpu/x86_64/misc/x86_64-gdbstub.c:156-162). Every consumer of that sentinel masks it with & 0x7f, turning "no gdb console exists" into the data byte 0x7f:

• putpacket() ack wait — sys/cpu/x86_64/misc/x86_64-gdbstub.c:277 while ((getDebugChar () & 0x7f) != '+');
• getpacket() start-char wait — x86_64-gdbstub.c:189
• getpacket() body/checksum — x86_64-gdbstub.c:200,211-212

When the kernel is asked to use the GDB remote debugger (boothowto & RB_GDB, set by boot -g, by debug.enter_debugger=gdb, or by a debugger-on-panic path) but no gdb console device was ever attached (no flag 0x80 sio port, no dcons, no COM ports at all), kdb_trap() still routes into the stub (sys/platform/pc64/x86_64/db_interface.c:105,179) and:

1. the stub's very first putpacket() (the T stop-reply, x86_64-gdbstub.c:531) faults: in the shipped gcc 8.3 kernel the .constprop clone of putpacket deleted the accessor NULL guards, so the first character emit executes gdb_tab->cn_putc(gdb_tab->cn_gdbprivate, …) with gdb_tab == NULL → page fault at putpacket+0x2c reading 0x68 (offsetof(struct consdev, cn_gdbprivate), sys/sys/cons.h:72), and
2. the fault re-enters kdb_trap() (trap.c:1096, db_active != 0) which re-routes to the stub, which faults identically — an unterminating Fatal trap 12 storm (~35 KB/s on serial) while the other CPUs sit IPI-stopped (db_interface.c:160-168).

Even in a hypothetical build that keeps the guards, every wait loop masks the getDebugChar() == -1 sentinel into data (-1 & 0x7f == 0x7f, x86_64-gdbstub.c:189,200,277), so putpacket()'s ack wait still can never exit — same permanent hang, silent instead of loud.

No ddb prompt, no gdb packet on the wire, no dump, no auto-reboot: the machine is permanently hung. Any later kernel panic (e.g. remotely triggerable crash) on such a box becomes a permanent hang instead of the usual dump-and-reboot.

How to reproduce (guest is single-tenant; serial console is output-only)

No build is required — the stock kernel carries the stub (X86_64_GENERIC, optional ddb).

1. ./run.sh — triggers sysctl debug.enter_debugger=gdb over ssh (production path: sys/ddb/db_sysctl.c:57-74 sets boothowto |= RB_GDB then calls Debugger()).
2. Expected (baseline, vulnerable kernel): the ssh command never returns (exit 124 after the 60 s timeout), the guest stops answering ssh entirely, QEMU keeps running, and the serial log shows the kdb banner CPU0 stopping CPUs: / stopped followed by eternal silence (no ddb banner, no $ packet — putDebugChar produced no bytes).
3. ./run_control.sh — same entry via debug.enter_debugger=ddb (differential control): serial shows the ddb banner + db> prompt, proving the trap entry works and only the gdb branch hangs silently. (Control run also wedges the guest at the db> prompt — the guest's serial console is -serial file: and accepts no input — recover with dfbsd-qemu/vm.sh reset with-src.)
4. Fix validation: fix.diff adds an early if (gdb_tab == NULL) return; to gdb_handle_exception. With the patched kernel the same trigger returns cleanly: the sysctl exits 0, echo STILL_ALIVE works, serial shows stopping/stopped/restarted. See run.patched.log.

Files

• run.sh / run_control.sh / run_patched.sh — exact runnable commands
• run.log / serial.baseline.txt — baseline hang (RC 124, wedged guest)
• run.control.log / serial.control.txt — ddb differential control
• run.patched.log / serial.patched.txt — fix validation
• fix.diff — one-guard fix (never applied to the read-only sys/ tree)
• env.txt — guest identity, symbols, CPU count
• VERDICT.md, manifest.json, verdict.json

DF-5475 — VERDICT

Status: reproduced (deterministic, stock X86_64_GENERIC kernel, first attempt). Impact: dos — permanent whole-machine hang (NULL-deref fault storm) with no dump, no reboot, no debugger output, on any kdb entry routed to the GDB stub while gdb_tab == NULL. Confidence: certain (live reproduction + disassembly of the faulting instruction in the shipped kernel binary). Fix: validated — the fault storm and the eternal non-returning kdb cycle are gone on the patched kernel (fix_patched_reproduced = false).

Root cause (line-accurate)

gdb_handle_exception() (sys/cpu/x86_64/misc/x86_64-gdbstub.c:448) is entered whenever boothowto & RB_GDB routes a trap away from DDB (sys/platform/pc64/x86_64/db_interface.c:105,174-179), regardless of whether a gdb console was ever attached. gdb_tab is only set by a flag 0x80 sio port (sys/dev/serial/sio/sio.c:3113-3120), by sio's boot-time fallback when a serial console exists (sio.c:3131-3141), or by dcons (FireWire). On hardware without any of those — yet booted with the documented boot -g flag, or after sysctl debug.enter_debugger=gdb (sys/ddb/db_sysctl.c:57-74, which sets boothowto |= RB_GDB before calling Debugger()) — gdb_tab is NULL and the stub runs anyway.

The stub's only defense is the per-call sentinel in the char accessors (x86_64-gdbstub.c:147-162):

static int putDebugChar (int c) { if (gdb_tab == NULL) return 0;  gdb_tab->cn_putc(gdb_tab->cn_gdbprivate, c); ... }
static int getDebugChar (void)  { if (gdb_tab == NULL) return -1; return gdb_tab->cn_getc(gdb_tab->cn_gdbprivate); }

and every consumer masks the sentinel into data (-1 & 0x7f == 0x7f): getpacket() start/body/checksum waits (x86_64-gdbstub.c:189,200,211-212) and putpacket()'s ack wait (x86_64-gdbstub.c:277 while ((getDebugChar () & 0x7f) != '+');). Source-wise that is already an unreachable-exit infinite loop with the other CPUs IPI-stopped (db_interface.c:160-168) and crit_enter() held.

In the actually shipped binary it is worse: gcc 8.3's .constprop clone of putpacket deleted the NULL guards of the inlined accessors. Disassembly of the stock guest kernel (/boot/kernel/kernel, putpacket.constprop.2 @ 0xffffffff80b94080):

ffffffff80b940a0: mov 0x789c79(%rip),%rax   # ffffffff8131dd20 <gdb_tab>
ffffffff80b940a7: mov $0x24,%esi            # '$'
ffffffff80b940ac: mov 0x68(%rax),%rdi       # gdb_tab->cn_gdbprivate  <-- NO NULL CHECK
ffffffff80b940b0: mov 0x30(%rax),%rax       # gdb_tab->cn_putc

0x68 is exactly offsetof(struct consdev, cn_gdbprivate) (sys/sys/cons.h:60-77). So the very first putpacket() — the T stop reply at x86_64-gdbstub.c:531 — faults at putpacket+0x2c reading 0x68.

Reproduction (baseline, stock kernel, -smp 6)

./run.sh over ssh as root:

sysctl debug.enter_debugger=gdb        # db_sysctl.c:71-73: boothowto |= RB_GDB; Debugger()

Observed (run.log, serial.baseline.txt):

Debugger("debug.enter_debugger")
CPU2 stopping CPUs: 0x0000003b
 stopped
Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0x68                     <- offsetof(consdev, cn_gdbprivate)
instruction pointer    = 0x8:0xffffffff80b940ac   <- putpacket+0x2c
current thread         = pri 6 (CRIT)

…repeating forever (~35 KB/s on serial; boot.log grew 2.4 MB → 5.4 MB during the observation window). Mechanism of the storm: the page fault traps into trap_fatal(), which re-enters kdb_trap() (sys/platform/pc64/x86_64/trap.c:1096, taken because db_active != 0), which re-routes to the stub, which faults identically — an unterminating fault-retry loop. The ssh trigger never returns (TRIGGER_RC=124), the guest stops answering entirely, QEMU keeps running (CPUs spinning). No ddb prompt, no dump, no reboot — a permanent hang.

Classification per the audit table: RUN_RC=124 + guest wedged = reproduced / dos.

Differential control (run.control.log, serial.control.txt)

Same production entry, DDB branch (sysctl debug.enter_debugger=ddb):

Debugger("debug.enter_debugger")
CPU3 stopping CPUs: 0x00000037
 stopped
Stopped at      Debugger+0x7c:  movb  $0,0xbdaf09(%rip)
db>

Trap entry, stop_cpus, and the console all work; only the gdb branch with gdb_tab == NULL dies silently. (The control guest then waits at the db> prompt — this rig's serial console is -serial file: with no input path, so that run also ends wedged-by-design and was recovered with vm.sh reset with-src.)

Threat model / severity

Precondition: boothowto & RB_GDB and no gdb console device. Both boot -g (loader flag, documented "use GDB remote debugger instead of DDB") and debug.enter_debugger=gdb (root sysctl) set the flag; neither checks that a gdb port exists, and nothing else in the entry path does either. On a box whose operator enabled -g (e.g. in loader.conf) but has no flag 0x80 serial port and no COM hardware at all, every kernel panic becomes a permanent hang instead of dump-and-reboot: a remote crasher converts a recoverable outage into an unrecoverable one. Availability-only, configuration-conditional → Low per the rubric, consistent with the other gdbstub findings (DF-1079/DF-1080/DF-2361/DF-2362).

Fix validation

fix.diff adds one guard at the top of gdb_handle_exception (after the declarations, x86_64-gdbstub.c:476):

if (gdb_tab == NULL)
        return;

Built in-guest (make nativekernel KERNCONF=X86_64_GENERIC + make installkernel, gcc 8.3, -Werror clean — build.log). The installed kernel's gdb_handle_exception now opens with cmpq $0x0,<gdb_tab> / je early-return (disassembly in build.log).

Re-run of the identical trigger:

• -smp 1 (run.patched.log, serial.patched.txt): the sysctl returns rc 0, STILL_ALIVE_OK prints, the machine keeps running; serial shows the complete clean cycle CPU0 stopping CPUs: 0x00000000 / stopped / restarting / restarted. The previously-fatal path is now a no-op trap bounce. fix_patched_reproduced = false — the DF-5475 behavior is gone.
• -smp 6: the fault storm is equally gone (serial shows the full stopped → restarted cycle, zero Fatal trap 12), kdb_trap() returns and the kernel core resumes (all vCPUs idle-halted, monitor-probed), but userland/interrupt delivery on this KVM guest subsequently wedged and a follow-up NMI's stop_cpus never completed — the other CPUs had stopped answering IPIs. This aftermath artifact is outside this file: it lives in the SMP Xcpustop stop/restart machinery (sys/platform/pc64/apic/apic_vector.s:239-326) and is exercised by any fast kdb stop/return cycle, not by the guard (which is proven clean by the -smp 1 run where no other CPUs exist). Reported here for the record; it deserves its own finding against apic_vector.s/mp_machdep.c; on this rig it could not be separated from ddb usage because the serial console accepts no input (ddb cannot be continued).

fix_baseline_reproduced = true, fix_patched_reproduced = false, fix_status = fixed (for the DF-5475 primitive: no fault storm, no eternal non-returning kdb cycle on the patched kernel).

Distinction from the known findings

DF-1079/DF-2362 (unbounded m/M length vs the 400-byte buffers) and DF-1080/DF-2361 (P regno bounds) are packet-parser memory-safety bugs that require a live serial peer. DF-5475 is the complement: the stub is entered and self-destructs before any packet is ever read, purely because the console it must speak through does not exist — including on the panic path, where no attacker-controlled serial traffic is involved at all.

Artifacts

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.