DF-5571 — vkernel64 kdb_trap() longjmp re-entry double-increments db_active (DF-5561 twin); the leak routes every subsequent trap into trap_fatal()+kdb_trap() — permanent all-CPU ddb wedge of the whole vkernel

What (twin of DF-5561, pc64)

kdb_trap() in sys/platform/vkernel64/x86_64/db_interface.c:

150:  if (db_global_jmpbuf_valid)
151:      longjmp(db_global_jmpbuf, 1);      /* nested trap while ddb is live */
...
167:  setjmp(db_global_jmpbuf);              /* re-entry lands here           */
168:  db_global_jmpbuf_valid = TRUE;
169:  db_active++;                           /* runs AGAIN on re-entry       */
...
177:  db_active--;                           /* the abandoned outer call's
                                              decrement NEVER runs           */

A fault taken while a ddb session is live (e.g. the ddb call 0x10() — db_fncall arms no fault guard) re-enters kdb_trap(), which longjmps back to the setjmp at :167; the increment at :169 executes a second time while the abandoned outer invocation's db_active-- at :177 never runs. After the session finally exits, db_active is stuck at >= 1 forever.

Consequence (vkernel64 trap.c routing): - user_trap() — trap.c:366: if (db_active) { trap_fatal(frame, TRUE, eva); ... } — every USER-mode trap - kern_trap() — trap.c:605: same for kernel traps - trap_fatal() — trap.c:959: if ((debugger_on_panic || db_active) && kdb_trap(...)) return;

so with the leaked counter, every ordinary trap (user page faults, ASTs, forced exceptions) is diverted into trap_fatal() + kdb_trap() → stop_cpus() (all-CPU stop via pthread_kill on the vcpu threads, mp.c:230-244) → db> prompt. The vkernel — a single host process hosting every guest "process" — wedges permanently in ddb; even the panic path re-enters ddb.

Trust model

Identical to DF-5561: requires an interactive ddb session in the vkernel (console operator, sysctl debug.enter_debugger=ddb as root inside the vkernel, SIGQUIT on the vkernel process = exc_debugger() → Debugger(), or a panic with debugger_on_panic). A ddb command that faults (e.g. call <bad addr>()) then poisons the session; every subsequent continue wedged the entire machine. Medium / local-DoS, deterministic.

Reproduce (as run on the QEMU guest, 2026-10-07)

Build prerequisites: 1. stock make nativekernel KERNCONF=VKERNEL64 fails to link (DF-5474: __build_id_start/end undefined) — apply linkfix-df5474.diff in the guest scratch tree first (validated link+boot, same as DF-5474). 2. sh mk_image.sh — pristine 96MB UFS /vkroot.img: /sbin/init=vkinit (opens /dev/console, execs /bin/sh), /bin/sh, /bin/sleep, /bin/fault (derefs 0x10), /lib/libc.so.8, /libexec/ld-elf.so.2. (vkinit is required: with -e init_path=/bin/sh the kernel-exec'd sh exits instantly — "init died (signal 0, exit 0)".)

sh vk_ddb_session.sh /usr/obj/usr/src/sys/VKERNEL64/kernel.debug baseline 0x11150a8

The driver (one ssh session) boots the vkernel (-m 256m -n 2 -s, fifo console), waits for userspace, then performs the trigger sequence: kill -QUIT <child> (the vkernel re-forks at startup, init.c:203; the parent ignores SIGQUIT) → at db>:

x/x 0x11150a8          # &db_active from nm — vkernel ddb has no symtab
call 0x10()            # fault inside ddb -> longjmp re-entry
x/x 0x11150a8          # counter now 2
c                      # continue; counter decrements to 1 (leaked)
/bin/fault             # from the shell: first user trap after continue
echo POSTCONT-ALIVE    # never executes in baseline

Expected — baseline (run.baseline.log)

• first prompt: 0x11150a8: 1
• after call 0x10() → "Fatal trap 12 ... ip=0x2b:0x10" → "kernel: type 12 trap" → re-entered db>: 0x11150a8: 2 ← the double-increment
• after c: Fatal trap 7: system forced exception while in user mode, current process = 1 (sh) → kernel: type 7 trap → CPU0 stopping CPUs → Stopped at ... (no prompt echo), then a nested Fatal trap 12 cascade
• echo POSTCONT-ALIVE → No such command (input now owned by ddb — the shell/whole OS is dead)
• driver exit closes the fifo → panic: vconsgetc: EOF → which re-enters ddb AGAIN (Debugger("panic")) — the wedge survives even a panic.

Expected — fixed (run.fixed.log)

• first prompt: 0x11150a8: 1
• after call 0x10() re-entry: 0x11150a8: 1 (guard if (db_active == 0))
• after c: /bin/fault handled as a normal user SIGSEGV: pid 2 (fault), uid 0: exited on signal 11 / Segmentation fault
• echo POSTCONT-ALIVE → printed by the shell
• "Fatal trap" count: 1 (only the intentional call 0x10() one) vs 5 in baseline; clean Caught SIGTERM ... Shutting down...

Fix validation

fix.diff (authored after verification, never applied to the audit tree): guard the re-entry increment. Applied in the guest scratch tree, vkernel rebuilt (build.log, RC=0, db_interface.o recompiled), identical sequence re-run: counter stays 1, no storm, no wedge. Fixed.

Files

• run.baseline.log / run.fixed.log — full untrimmed vkernel consoles
• vk_ddb_session.sh — the phase driver (trigger sequence)
• mk_image.sh, vkinit.c, fault.c — root-image rig
• linkfix-df5474.diff — prerequisite DF-5474 link fix
• fix.diff — the fix; build.log — patched rebuild
• env.txt, hashes.txt
• VERDICT.md, manifest.json, verdict.json

DF-5571 VERDICT — REPRODUCED (deterministic, live vkernel64 on the QEMU guest)

Bottom line

The DF-5561 lead is confirmed byte-for-byte on the vkernel64 twin. kdb_trap()'s db_global_jmpbuf re-entry path re-executes db_active++ (sys/platform/vkernel64/x86_64/db_interface.c:169) while the abandoned outer invocation's db_active-- (:177) never runs, permanently leaking db_active >= 1; user_trap() (trap.c:366) and kern_trap() (trap.c:605) then route every subsequent trap — including ordinary user-mode traps — into trap_fatal() + kdb_trap(), wedging the entire vkernel in ddb. Verified on a live vkernel booted inside the QEMU guest: counter read 1 -> call 0x10() fault -> counter read 2 at the re-entered prompt -> c -> user-mode trap 7 from PID 1 (sh) taken to trap_fatal + all-CPU stop + ddb + nested-fault cascade; echo POSTCONT-ALIVE eaten by ddb ("No such command"); even the driver-exit EOF panic re-entered ddb. With the one-line guard (if (db_active == 0) db_active++;), the same sequence keeps the counter at 1, /bin/fault gets normal SIGSEGV delivery, the shell answers, and the machine shuts down cleanly. Fix validated on a rebuilt vkernel.

Mechanism (path:line)

1. Entry: SIGQUIT on the vkernel child process → exc_debugger() (exception.c:277) → Debugger() (db_interface.c:340) → breakpoint() → host SIGTRAP → exc_segfault() → kern_trap() → T_BPTFLT → kdb_trap(3, 0, frame) (trap.c:714 area). (Also reachable via sysctl debug.enter_debugger=ddb → db_sysctl.c:73 and via any panic.)
2. First entry: ddb_regs = *regs (:156), crit_enter() (:158), stop_cpus (:163), setjmp(db_global_jmpbuf) (:167), db_global_jmpbuf_valid = TRUE (:168), db_active++ (:169) → 1, db_trap() prompt.
3. Nested fault inside ddb: call 0x10() executes in the vkernel process; unmapped → host SIGSEGV → exc_segfault → kern_trap → db_active nonzero → trap.c:605 → trap_fatal (prints "Fatal trap 12 ... instruction pointer = 0x2b:0x10") → nested kdb_trap(12, ...); switch default → db_printf("kernel: type 12 trap, code=0") (:136) → db_nofault NULL (db_fncall arms no guard) → db_global_jmpbuf_valid TRUE → longjmp(db_global_jmpbuf, 1) (:150-151).
4. The longjmp restores the FIRST invocation's setjmp context (:167); execution continues: db_active++ (:169) → 2; the nested invocation's frame (and its would-be db_active-- at :177) is abandoned. Re-entered db_trap() prompt.
5. c: db_active-- (:177) → 1 (leaked), restart_cpus (:192), regs restored from ddb_regs (first trap's frame — the nested invocation longjmp'd before ddb_regs = *regs at :156, so ddb_regs still holds the original frame), return 1 (:225) → the SIGQUIT entry unwinds normally.
6. Leak in action: the next user-mode trap (observed: "Fatal trap 7: system forced exception while in user mode, current process = 1 (sh)") hits trap.c:366 → trap_fatal → kdb_trap → stop_cpus → ddb — no path back to userland. Subsequent faults cascade inside the wedged ddb (nested Fatal trap 12 while printing the stop line), and the driver-exit EOF reached panic("vconsgetc: EOF") which itself re-entered Debugger("panic") — the wedge survives panic.

Reproduction runs (guest: DragonFly 6.5-DEVELOPMENT, QEMU/KVM)

Baseline (run.baseline.log, stock vkernel built from the audited tree + DF-5474 link fix):

db> x/x 0x11150a8                 # &db_active (nm: 00000000011150a8 B db_active)
0x11150a8:      1
db> call 0x10()
Fatal trap 12: page fault while in kernel mode ... ip=0x2b:0x10
kernel: type 12 trap, code=0
Stopped at 0x71cad9 ...
db> x/x 0x11150a8
0x11150a8:      2                  # <-- DOUBLE INCREMENT
db> c
CPU0 restarting CPUs ... restarted
Fatal trap 7: system forced exception while in user mode
current process = 1 (sh)          # ordinary user trap -> trap_fatal
kernel: type 7 trap, code=4
CPU0 stopping CPUs ... stopped    # all-CPU stop on a user AST-class trap
[nested Fatal trap 12 cascade]
db> echo POSTCONT-ALIVE
No such command                   # shell dead; ddb owns the console
[driver exit -> panic: vconsgetc: EOF -> Debugger("panic") -> ddb again]

Fixed (run.fixed.log, fix.diff applied + rebuilt, RC=0):

db> x/x 0x11150a8
0x11150a8:      1
db> call 0x10()
Fatal trap 12 ... kernel: type 12 trap, code=0
db> x/x 0x11150a8
0x11150a8:      1                  # <-- GUARD HELD
db> c
/bin/fault
fault: about to deref 0x10
pid 2 (fault), uid 0: exited on signal 11
Segmentation fault                 # normal user SIGSEGV delivery
# echo POSTCONT-ALIVE
POSTCONT-ALIVE                     # shell alive
Caught SIGTERM from host system. Shutting down...

"Fatal trap" occurrences: baseline 5 vs fixed 1 (the intentional one).

Rig notes (what had to be fixed vs the naive sketch)

• vkernel ddb has no symbol table: print *db_active / print *(int*)addr both fail ("Symbol not found") — read the counter by literal address with x/x (address from nm kernel.debug, stable across the patched relink: 0x11150a8 both builds).
• The vkernel re-forks at startup (init.c:203) and the parent sets SIGQUIT→SIG_IGN (init.c:210): signal the CHILD, not the launcher pid.
• exec -a is not supported by the guest /bin/sh.
• With -e init_path=/bin/sh the kernel-exec'd sh dies instantly ("init died (signal 0, exit 0)") — use a /sbin/init (vkinit.c) that opens /dev/console itself and execs sh.
• The vkernel console input in ddb is vconsgetc() = blocking pread(0) (console.c:404-420): drive it through a fifo whose write end is held open for the whole session, or EOF → panic("vconsgetc: EOF").
• The vkernel boot wipes the MBR of its root image (vkd writes): rebuild the image pristine (mk_image.sh) before every phase.
• Stock make nativekernel KERNCONF=VKERNEL64 does not link on this tree (DF-5474): apply linkfix-df5474.diff first.
• Fault/trap host signals are SA_NODEFER + empty mask (exception.c:223-228) so the abandoned nested handler leaves no signal-mask residue — the only lasting corruption is the db_active leak itself.

Severity / impact ceiling

Medium (local DoS), matching DF-5561: the trigger needs an interactive ddb session (console operator / root inside the vkernel / panic-time debugger_on_panic), but a single faulting ddb command then bricks the whole virtual machine with no dump, no reboot, and no remote access. No memory corruption is involved (the primitive is a leaked integer flag), so there is no uid-0 route; impact ceiling is permanent wedge of the vkernel process and everything hosted in it.

Adjacent observations (not filed — different file)

• trap.c:368/607 gd_trap_nesting_level balances its own ++/-- around trap_fatal, so the longjmp abandonment does NOT leak it in vkernel64 (unlike pc64's trap.c noted in DF-5561).
• vkernel64 lacks pc64's if (panicstr == NULL) guard around the stopped_cpus mask check / restart_cpus (db_interface.c:185-192 vs pc64): a stop_cpus partial failure during a panic-time ddb entry panics recursively. Triggerability marginal (stop_cpus fails only on pthread_kill error, mp.c:240).
• vconsgetc() panics on console EOF (console.c:416) — rig fragility, not attacker-reachable beyond the wedge itself.
• db_read_bytes/db_write_bytes (:231-307): identical nofault-guard shape to pc64, coherent; the RW-text remap code is #if 0'd in both.

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.