DF-4606 VERDICT

Status: reproduced (mechanism-level, deterministic) — impact: dos

What was run

Three guest runs (2026-09-22, DragonFly 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026, X86_64_GENERIC, 6 vCPU, PIIX3 IDE w/ acd0, KVM):

1. Run 1 (first module version): my canceller forgot to actually lockmgr(&lk, LK_EXCLUSIVE) before callout_cancel — the kernel panicked at lockmgr_cancel_beg kern_lock.c:989 KKASSERT((count & (LKC_XMASK|LKC_SMASK)) != 0) ("lock must be held when issuing LK_CANCEL_BEG"). Accident, but useful: it proves callout_cancel on a mid-execution (INPROG) AUTOLOCK callout takes the LK_CANCEL_BEG cancel path (kern_timeout.c:892) while the callback is between its internal LK_RELEASE and re-acquire. The real nata callers (ata-lowlevel.c:442 from ata_interrupt, ata-all.c:208 from ata_reinit, ata-queue.c:578 from ata_fail_requests) all hold ch->state_mtx, so they satisfy that assertion — and then deadlock as described below.
2. Run 2: harness had a softclock-thread tsleep(..., timeout) — illegal in a softclock callback (its own timeout is serviced by itself). Replaced with a busy rendezvous. Even so the system wedged: userspace sleep 2 never returned (RUN_RC=124), and orderly shutdown hung ("timeout expired. Shutdown terminated.", stuck at "syncing disks... 0" on the serial console — full excerpt in run.log).

3. Run 3 (decisive): deterministic rendezvous + hw.df4606_progress sysctl probe. Output (run.log):

   df4606: armed; watch for the wedge df4606: [softclock] callback: framework holds lk, dropping it (== ata-queue.c:557) df4606: [canceller] acquired lk inside the window (== late ata_interrupt with state_mtx) df4606: [canceller] calling callout_cancel() (== ata-lowlevel.c:442) ... hw.df4606_progress: 3 ← callback entered the re-acquire lockmgr B5 costp df4606c ← canceller parked in _callout_cancel_or_stop's ssleep kldunload: can't unload file: Device busy

progress=3 (set immediately before lockmgr(&lk, LK_EXCLUSIVE)) and never 4 proves the softclock thread is permanently blocked in the re-acquire — the exact statement of the finding. The canceller's wchan costp is the literal sleep channel of kern_timeout.c:920. Orderly shutdown of the wedged guest again failed (vm.sh down force-killed QEMU; wedge-serial.log).

Why this is the finding's mechanism and not an artifact

• The KLD uses the same primitives the nata path uses: callout_init_lk(&co, &lk) == ata-queue.c:93; the callback's LK_RELEASE/LK_EXCLUSIVE pair == ata_timeout's ata-queue.c:557/560; the canceller's hold-the-lock + callout_cancel == ata-lowlevel.c:442 / ata-all.c:208 / ata-queue.c:578.
• The kernel side is unmodified (stock guest kernel; the module only uses the public callout/lockmgr API exactly as ata does).
• No timing luck is needed in the KLD because the rendezvous pins the interleaving; the ATA code admits the same interleaving whenever the completion lands in its (unpinned, sub-ms) window after a ≥10 s stall.

Why not reproduced in-situ on the ATA path

The ATA trigger needs (a) a request that times out — the emulated PIIX3 channel completes 512 MB in 0.69 s (see DF-4607/stress.log), so timeouts never fire — and (b) the completion to land inside the callback's window. There is no user- or root-controllable way to stall QEMU's IDE from inside the guest (no CD medium, no monitor access from the guest). The window and all three interleaving entry paths are proven by the source trace in README.md; the interleaving semantics are proven by the KLD. In-situ exploitation is a hardware-reliability event (failing/slow disk, aggressive PM), after which the kernel wedges permanently.

Exploit chain

Not a corruption primitive; the deliverable is denial of service: any unprivileged IO can be the request that times out on a slow/failing channel; the kernel then deadlocks ch->state_mtx + one softclock thread, hanging the boot-disk channel and all timers that land on the wedged CPU's callwheel. No uid=0 route exists for this class.

Fix

fix.diff: ch->running = NULL; in ata_timeout while still holding state_mtx (what the comment at ata-queue.c:551-553 already claims the code does). fix_status=not_testable: validating it requires staging the in-situ timeout+late-completion interleave, which the guest hardware cannot produce; the KLD reproduces the primitive, not the ata path, so patching ata-queue.c cannot change the KLD's outcome by construction.

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.