DF-5533 — usb_proc_drain() cold-path: unconditional suspend_kproc() hang

File: sys/bus/u4b/usb_process.c (pass 2)

What this demonstrates

usb_proc_drain()'s cold-boot branch (usb_process.c:433-439):

if (cold) {
        USB_THREAD_SUSPEND(up->up_ptr);   /* suspend_kproc(p, 0) */
        kprintf("WARNING: A USB process has been left suspended\n");
        break;
}

calls suspend_kproc() (sys/kern/kern_kthread.c:188-204), which tsleeps until the target thread acknowledges TDF_MP_STOPREQ — but usb_process() never runs any suspend check: the intended USB_THREAD_SUSPEND_CHECK() at usb_process.c:86-89 is #if 0'd out, and the macro it expands to (kthread_suspend_check(curproc), usb_process.c:60) does not exist anywhere in the DragonFly kernel (the real primitive is kproc_suspend_loop(), used by bufdaemon/ syncer/vfs_mount). The drain thread therefore sleeps forever in "suskp" while holding the USB bus lock, and the USB process thread can never acquire the lock to exit either → permanent double-wedge.

Reachability: cold is true during autoconfiguration; a USB controller attach failure reaching usb_proc_free()/usb_proc_drain() (sys/bus/u4b/controller/usb_controller.c:210-236, 879-900 error path) during boot wedges the boot with the bus lock held. Not attacker- reachable in the standard configuration — this is a hardware/ hypervisor-triggered boot DoS (Low).

Build / run (on the QEMU guest, as root)

Same harness as DF-5532 (dfharness.c):

cd /root/dfharness && make && kldload ./dfharness.ko
sleep 1; sysctl kern.dfstarv.stop=1      # quiesce the churn demo
sleep 2
nohup sh -c 'sysctl kern.dfcold.fire=1; echo rc=$?' > /root/fire.log 2>&1 &
sleep 3;  cat /root/fire.log            # EMPTY: never returned
ps -axH -o pid,stat,wchan,comm | grep -E 'dfhz|sysctl'
# -> sysctl thread in D-state, wchan "suspkp"; no WARNING printed

Expected (baseline, unpatched kernel)

1028  D1  suspkp  sysctl      # uninterruptible, forever
fire.log empty (no return, and usb_process.c:437's WARNING never prints)

Fix

fix.diff (shared with DF-5532; validated in the same patched-kernel build): (1) loop-top USB_THREAD_SUSPEND_CHECK() → kproc_suspend_loop() (the existing DF daemon idiom), (2) release the bus lock around suspend_kproc() so the target can actually run its suspend check.

DF-5533 VERDICT — REPRODUCED (dos, boot-time)

Bottom line

usb_proc_drain()'s cold-boot branch (sys/bus/u4b/usb_process.c:433-439) calls USB_THREAD_SUSPEND(up->up_ptr) = suspend_kproc(td, 0) (sys/kern/kern_kthread.c:188-204). suspend_kproc() sets TDF_MP_STOPREQ on the target thread and tsleep(td, 0, "suspkp", 0) — sleeping forever (timo=0) until the target acknowledges the stop request. But the usb_process() dispatcher thread never acknowledges anything:

• the only suspend check is #if 0'd out at usb_process.c:86-89, and
• even if it were live, the macro it expands to — kthread_suspend_check(curproc) (usb_process.c:60) — does not exist in the DragonFly kernel (grep: zero definitions; the real primitive is kproc_suspend_loop(), kern_kthread.c:209).

Additionally, suspend_kproc() is called while the drain thread still holds up->up_lock (acquired at usb_process.c:417) and its tsleep(td, ...) variant releases no lock — so the USB process thread, which usb_proc_drain() just cv_signal()ed at usb_process.c:428-431, cannot re-acquire the lock to run its up_gone exit either. Both threads freeze permanently; every later taker of that USB bus lock joins the wedge.

Reproduction (QEMU guest, unpatched kernel)

Harness sysctl kern.dfcold.fire=1 (dfharness.c) sets cold=1 and calls usb_proc_drain() on a live usb_process — the exact code path a USB controller attach-failure takes during autoconfiguration via usb_proc_free()/usb_proc_drain() (sys/bus/u4b/controller/usb_controller.c:210-236, 879-900).

Observed (run.log):

• the sysctl kern.dfcold.fire=1 process went to D1 state, wait channel suspkp, and stayed there for the whole observation window (11+ s; it is still there at guest reset);
• /root/fire.log — which captures the sysctl's return and the echo rc=$? — stayed empty: usb_proc_drain() never returned and the kprintf("WARNING: A USB process has been left suspended") at usb_process.c:437-438 never printed (it is after the never-returning call);
• the dfhz usb_process thread sat in B-state (blocked re-acquiring the bus lock the wedged drain thread holds);
• the rest of the guest kept running: the wedge is bounded to the drain thread + the usb_process + future takers of that bus lock — which, at real boot time, includes the whole USB subsystem teardown path on that controller.

Impact

Boot-time denial of service, hardware/hypervisor-triggered (a USB controller whose attach fails during cold autoconfiguration — faulty hardware, or a QEMU/KVM configuration presenting a broken xhci/ehci). Not remotely or locally attacker-triggerable in the default configuration → Low severity, dos impact.

Fix validation

fix.diff (in this pack; shared with DF-5532's, validated in the same patched-kernel build) does two things:

1. loop-top USB_THREAD_SUSPEND_CHECK(); in the dispatcher, with the macro fixed to the real primitive kproc_suspend_loop() — the same idiom every DragonFly kernel daemon uses (vfs_bio.c:2251, vfs_sync.c:379, subr_prf.c:931, vfs_mount.c:529);
2. release up->up_lock around suspend_kproc() so the target thread can actually run its suspend check instead of deadlocking on the lock the suspender holds while sleeping.

On the patched kernel, sysctl kern.dfcold.fire=1 returns immediately, the WARNING prints, and no D-state thread is left on the sysctl path (the usb_process thread is intentionally left parked suspended — exactly what the WARNING text promises).

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.