DF-4415 — atkbdc.c unbounded polling loops under i8042/AUX data flood (missing the timeout cap that empty_both_buffers has)

Build

cc -O2 -Wall -o /tmp/psm_reach DF-4415/psm_reach.c

Run (as an unprivileged user)

/tmp/psm_reach

What it demonstrates (reproduced on the audit guest)

• /dev/psm0 is created world read/write (crw-rw-rw-) — any local user reaches the psm driver and, through it, the atkbdc controller layer (atkbdc0 backing psm0 per dmesg).
• MOUSE_GETHWINFO and MOUSE_SETMODE succeed for uid 1999 — MOUSE_SETMODE drives psm → send_aux_command → write_aux_command → wait_while_controller_busy() etc., i.e. the atkbdc busy-wait pollers, on every call. Worst observed round-trip 7.4 ms with the healthy QEMU i8042 (the pollers only burn their full 70-200 ms × 3 retries when the controller is slow/wedged).

What it cannot demonstrate from guest userspace

The genuinely unbounded loops need the controller/EC to keep presenting data faster than the code drains it (hostile EC, or a VM host's i8042 device model). Guest userspace has no port-I/O path (/dev/io is root-only crw-------), so the flood cannot be injected from inside the guest; those loops are:

• empty_kbd_buffer() — sys/dev/misc/kbd/atkbdc.c:865-882 (t = wait reset on every byte)
• empty_aux_buffer() — atkbdc.c:905-922 (same pattern)
• read_kbd_data_no_wait() — atkbdc.c:799-804 (while (f == KBDS_AUX_BUFFER_FULL))
• read_aux_data_no_wait() — atkbdc.c:838-843 (while (f == KBDS_KBD_BUFFER_FULL))

empty_both_buffers() (atkbdc.c:934-978) carries an explicit overall cap (waited, added for "Intel/IBM blades" that exhibit exactly this controller-flood hang) — the four siblings above never got the same treatment.

DF-4415 — VERDICT

status: not_reproduced for the unbounded loop itself (needs controller/EC data flood — hardware injection); the unprivileged reachability of the affected code paths WAS reproduced live

What was reproduced on the guest (DF 6.5-DEVELOPMENT, atkbdc0+psm0, QEMU i8042)

• /dev/psm0 is world read/write (crw-rw-rw-), /dev/kbd0 /dev/kbd1 are root-only.
• As uid 1999: open("/dev/psm0") OK; MOUSE_GETHWINFO returns a real PS/2 mouse (buttons=5, iftype=3, hwid=4 — psm0: model IntelliMouse Explorer, device ID 4 on atkbdc0); 20× MOUSE_SETMODE all succeed, worst latency 0.0074 s.
• Every MOUSE_SETMODE reprograms the aux device through send_aux_command() (atkbdc.c:647-670) → write_aux_command() (:616) → write_controller_command() (:586) → wait_while_controller_busy() (:417-439) and wait_for_aux_ack() (:545-569) — the DELAY()-busy poll chain. On a healthy controller this is single-digit milliseconds; the code burns up to ~70-200 ms × KBD_MAXRETRY(3) per command when the controller stalls (TOTALDELAY-bounded — a CPU-burn amplifier for any unprivileged user spamming psm ioctls, but bounded).

The actual defect (not demonstrable from guest userspace)

Four drain loops reset their budget on every received byte and have no overall cap, so a controller that keeps streaming data wedges the kernel thread indefinitely:

• empty_kbd_buffer() atkbdc.c:865-882 — t = wait; on each byte
• empty_aux_buffer() atkbdc.c:905-922 — same
• read_kbd_data_no_wait() atkbdc.c:799-804 — while (f == KBDS_AUX_BUFFER_FULL) keeps reading
• read_aux_data_no_wait() atkbdc.c:838-843 — mirror image

The maintainer-acknowledged precedent is in the same file: empty_both_buffers() atkbdc.c:959-966 has a waited cap with the comment "Some systems (Intel/IBM blades) do not have keyboard devices and will hang in this procedure. Time out … to avoid this hang". The four siblings never received the cap.

Threat model

Malicious/slow EC or i8042 device model (embedded coreboot ECs, VM hosts — the file's own quirk table documents "imperfect i8042 emulation" coreboot ECs at atkbdc.c:112-128), or a controller wedge during unprivileged ioctl storms through /dev/psm0. Impact: permanent kernel busy-loop (thread wedge / CPU starvation) → Low (hardware precondition).

Fix

Port the waited cap to the two empty_*_buffer() functions and bound the two read_*_no_wait() drain loops. See fix.diff.

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.