No common lock between linesw[] mutation and dispatch — register/deregister swap entries under tty_token while TIOCSETD (t_token+p_token) and driver read/write/ioctl paths read the table under unrelated locks, permitting torn multi-pointer swaps

Summary

ldisc_register/ldisc_deregister mutate linesw entries with whole-struct copies (nine function/data pointers, not atomic) while holding only tty_token. But the dispatch consumers do NOT hold tty_token: ttioctl takes tp->t_token + p->p_token and its TIOCSETD close/open dance reads linesw[].l_close/l_open; driver dispatch sites (sio, usb_serial, nmdm, syscons, dcons, vkernel console) hold only their own locks. A kldload/kldunload running concurrently with an ioctl or driver dispatch can therefore observe a half-old/half-new linesw entry — e.g. TIOCSETD pairing the old disc's l_close with the new disc's l_open, or a read entering a discipline mid-teardown. Every transient pointer value is still-mapped kernel text, so the immediate effect is wrong-disc dispatch/ENODEV/DoS rather than direct corruption; the dangerous residual is the widened window where a thread holds a stale module function pointer across the linker freeing the module text (classic unload-execution race, root-initiated). Attacker model: privileged kldload/kldunload racing unpriv TIOCSETD/read/write churn. Not guest-verified (Low, privileged trigger per contract). Fix: snapshot the linesw entry under tty_token on the dispatch side then dispatch through the snapshot (production fix should be RCU/epoch or registry token held only for the fetch; row sketch for TIOCSETD).

Timeline

• 2026-09-02 Discovered during pass-2 audit of tty_conf.c (GLM 5.3).