DF-5100 — joyread() spins inside crit_enter() against WALL-CLOCK nanotime()

What

joyread() enters a critical section (crit_enter(), joy.c:190) and busy-loops reading the game port until wall-clock nanotime() passes start + timeout (joy.c:192-211), then crit_exit() (joy.c:213).

nanotime() is realtime: it adds the global basetime, which settimeofday()/NTP steps mutate (sys/kern/kern_clock.c:1562-1587, specifically tsp->tv_sec += bt->tv_sec at kern_clock.c:1581).

Defect mechanics

• By design (1995 ISA driver): each read() masks interrupts and preemption on its CPU for up to timeout microseconds — max 10000us via JOY_SETTIMEOUT (joyioctl, joy.c:243). That alone is a 10ms interrupt-masked spin per read.
• The bug: the loop deadline is in wall time. A backward clock step (root settimeofday(2), or an NTP daemon step — ntpd runs as root and steps by default) while a reader is inside the loop moves nanotime() backward, while end = start + timeout stays fixed; timespeccmp(&t, &end, <) keeps the loop spinning until the wall clock again passes end. A backward step of N seconds holds that CPU in a critical section (interrupts masked, preemption blocked, IPIs deferred) for ~N extra seconds. Nothing in the loop re-reads timeout, and the only exits are the wall-clock comparison and both-axis completion.

Security impact

Root-gated (/dev/joy* is 0600 root, joy.c:133): an unprivileged user cannot trigger it, and root alone can already stall the machine. The realistic scenario is root running a joystick reader while the time daemon steps the clock — a latent local DoS / latency hazard. Filed as Info hardening; the fix is to use monotonic time (nanouptime(), sys/sys/time.h:185) for the measurement loop.

Build / run (as executed on the audit guest)

cc -O2 -Wall -o joy_crit_loop joy_crit_loop.c     # -> BUILD_OK, no warnings
./joy_crit_loop

Expected on hardware with /dev/joy0: five read N: ~10000 us lines, each an interrupt-masked spin; a concurrent date -v-N-style backward settimeofday() extends individual reads by ~N seconds. Observed on this guest: exit 2, open /dev/joy0: No such file or directory (errno=2) — joy(4) never attaches (no ISA gameport; kldload joy alone creates no node). See run.log, env.txt.

Fix

Swap nanotime() → nanouptime() at joy.c:193 and joy.c:204 (see fix.diff). Monotonic time is the correct base for a bounded busy-wait deadline.

DF-5100 VERDICT

Status: inconclusive (not runtime-exercisable on this guest) — mechanism proven from source; Info hardening finding, PoC skipped per contract.

Reproduced?

No — same environment blocker as DF-5099: joy(4) is module-only and the guest has no ISA gameport, so /dev/joy0 does not exist (ENOENT at open(), run.log). The trigger builds cleanly on the guest (cc 8.3, -Wall, zero diagnostics).

Why the defect is real anyway (source proof)

• joyread() calls crit_enter() (joy.c:190) and then busy-loops (joy.c:200-211) reading the port and calling nanotime(&t) until the wall clock passes end = start + timeout (computed at joy.c:193-196).
• nanotime() is realtime — it adds the global basetime (sys/kern/kern_clock.c:1562-1587, tsp->tv_sec += bt->tv_sec at 1581), and basetime is exactly what settimeofday()/NTP steps change.
• Therefore a backward clock step during the loop moves the sampled t backward while end stays fixed in wall time; timespeccmp(&t,&end,<) keeps the loop spinning until wall time catches up — holding the CPU in a critical section (interrupts masked, preemption and IPIs deferred) for up to ~step-magnitude seconds. The loop never re-reads timeout and has no other deadline.
• Baseline behavior even without a step: every read masks interrupts on its CPU for up to 10 ms (JOY_SETTIMEOUT max, joy.c:243).

Impact ceiling

Root-gated (joy.c:133, node 0600 root): only root can hold the device open, and root can stall the system by other means. The realistic risk is a root joystick reader combined with an NTP backward step — a latent local DoS/latency hazard. Info severity.

Why no fix validation

Same as DF-5099: the guest kernel never instantiates the device, so neither baseline nor patched behavior is observable. fix.diff (nanotime → nanouptime at the two call sites; nanouptime exists at sys/sys/time.h:185) is correct by construction — the monotonic clock makes the deadline immune to wall-clock steps — but was not kernel-built.

Kernel references

• sys/dev/misc/joy/joy.c:190-213 (crit_enter + wall-clock bounded busy loop)
• sys/dev/misc/joy/joy.c:193,195-196,204 (nanotime use / deadline math)
• sys/kern/kern_clock.c:1562-1587 (nanotime = realtime, adds stepped basetime)
• sys/dev/misc/joy/joy.c:243 (timeout capped 1..10000 us)
• sys/sys/time.h:185 (nanouptime — the monotonic fix)

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.