DF-4637 — vpoio: uninterruptible 500K/5M-iteration handshake spins run under vpo_intr's hard critical section

File: sys/dev/disk/vpo/vpoio.c (pass 2, GLM 5.3) Family: DF-4618 (immio.c instance, just filed) — this is the vpoio.c instance of the same family; distinct code, distinct spin sites, shared caller crit_enter() wrapper.

Reproduce (requires hardware the audit guest does not have)

Build: nothing to build — the trigger is ordinary disk I/O.

Run (on a machine with a real or emulated parallel port, ppc attached, kldload vpo, a ZIP drive behind it enumerating as /dev/daN):

# Malicious ZIP emulator: attach a parallel-port device emulator that answers
# the VP0 select/connect handshakes but then simply never asserts nBUSY during
# the data/status phases.
dd if=/dev/da1 of=/dev/null bs=512 count=1     # any I/O works

Expected (per source trace): each command phase wait spins up to 500,000 port reads (VP0_FAST_SPINTMO), each completion-phase wait up to 5,000,000 (VP0_LOW_SPINTMO), all inside crit_enter()/crit_exit() (vpo.c:215/323) — the issuing CPU runs with preemption disabled and interrupts deferred for the full spin (order seconds per I/O on LPC-class port I/O), unkillable, repeatable per command. Watchdog/soft-lockup messages, missed timers, network RX drops on that CPU.

Status

untested — the audit guest has no parallel-port hardware at all (dmesg/pciconf empty for ppc/ppbus/lpt; vpo.ko is present but cannot attach). Mechanism is source-certain: see VERDICT.md for the line-by-line trace. Family convention: DF-4618 / DF-4508 (hardware-gated, untested, attempts 0).

DF-4637 VERDICT — vpio handshake spins under vpo_intr's critical section

Status: untested (hardware-gated; no ppbus/ppc/lpt on the audit guest — env.txt). Mechanism: source-certain. Confidence: likely (same as DF-4618: the code path is unambiguous; the exploit premise — a malicious parallel-port ZIP emulator — is the driver's stated threat model and cannot be simulated on the QEMU guest).

Root cause (line-by-line)

vpoio_do_scsi() executes the entire SCSI-ish transaction synchronously in the caller's thread. Its callers in vpo.c wrap it in a hard critical section:

• sys/dev/disk/vpo/vpo.c:215 — crit_enter();
• sys/dev/disk/vpo/vpo.c:224-228 — vpoio_do_scsi(&vpo->vpo_io, ...) (main I/O)
• sys/dev/disk/vpo/vpo.c:278-284 — second vpoio_do_scsi() for REQUEST_SENSE (still inside the same crit section)
• sys/dev/disk/vpo/vpo.c:323 — crit_exit();

Inside vpoio_do_scsi() every device handshake is a pure busy-wait microsequence with no sleep, no yield, no interrupt escape:

• sys/dev/disk/vpo/vpoio.c:59 — VP0_FAST_SPINTMO 500000 iterations
• sys/dev/disk/vpo/vpoio.c:60 — VP0_LOW_SPINTMO 5000000 iterations
• vpoio_wait() (vpoio.c:525-558) executes wait_microseq (vpoio.c:103-113): MS_SET(tmo); loop: MS_BRSET(nBUSY, ready) + MS_DBRA(-2). In the ppbus engine (sys/dev/misc/ppc/ppc.c):
• MS_OP_BRSET (ppc.c:1453-1458) reads the status register each iteration (r_str → bus_space_read_1),
• MS_OP_DBRA (ppc.c:1447-1451) decrements ppc->ppc_accum and branches back. That is while (--tmo > 0) { if (status & nBUSY) break; } — nothing else.

Spin call sites inside vpoio_do_scsi, all reached under vpo_intr's crit:

• vpoio.c:705 → vpoio_select() — select wait, VP0_SELTMO=5000 (vpoio.c:498-500)
• vpoio.c:716 — command phase, VP0_FAST_SPINTMO per CDB byte (≤16 per command)
• vpoio.c:733 — data/completion phase, VP0_LOW_SPINTMO (5,000,000 iterations)
• vpoio.c:774 — status phase, VP0_FAST_SPINTMO

Worst case per single I/O against a device that never asserts nBUSY: 5000 (select) + 16×500,000 (command) + 5,000,000 (data) ≈ 13M port-I/O iterations under one crit_enter(), plus a possible full second round for autosense (vpo.c:278-284). At ~0.5–2 µs per LPC port read that is tens of seconds per I/O with preemption disabled and interrupts deferred on the issuing CPU. The wait loop in vpoio.c:533-538 (#if 0 /* broken */) shows an interruptible ppb_poll_device() variant was attempted and abandoned.

Threat model / reachability

• Stated threat: malicious parallel-port ZIP emulator (device-side attacker). It only has to withhold nBUSY — no protocol violation needed. Every issued command (any user I/O to the vpo-backed da device — raw device nodes are group-readable by operator; plus every scheduled backup/scan as root) pays the full spin.
• Weaker variant: a faulty cable/dongle or a wedged drive produces the same stall.
• CAM serializes commands (VP0_OPENNINGS=1, devq maxopenings=1, vpo.c:151/156), so this is a per-I/O livelock, not a concurrency bug — it is the duration under crit_enter() that makes it a hard stall (interrupt blackout), not a race.

Why not higher severity

Requires physically-attached malicious hardware (or the same class of HW fault) — same reasoning as DF-4618 (Low) and the ig_hal stuck-semaphore family (DF-4306/DF-4508, Low). Availability impact only.

Fix

Short-term (this pack's fix.diff): cut the spin ceilings 10x as the family mitigation. Proper fix: remove the crit_enter() around the synchronous transaction in vpo_intr (vpo.c) — the ppbus ownership lock already serializes the bus — and/or port vpoio_wait() to the interruptible ppb_poll_device() path the author stubbed at vpoio.c:533-538.

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.