CVE-2026-80628: ALSA: seq: oss: Serialize readq reset state with q->lock
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: oss: Serialize readq reset state with q->lock
sndseqossreadqclear() resets qlen, head, and tail without q->lock even though the normal reader and producer paths serialize the same ring state under that spinlock. A reset can therefore race sndseqossreadqfree() or sndseqossreadqputevent() and leave stale records in the queue, drop freshly queued ones, or report the wrong readiness after wakeup. KCSAN reports a data race between sndseqossreadqclear() and sndseqossreadqfree().
Take q->lock while clearing the ring and resetting inputtime. Factor the enqueue logic into a caller-locked helper so sndseqossreadqputtimestamp() updates its suppression state under the same lock instead of racing the reset path.
The buggy scenario involves two paths, with each column showing the order within that path:
reset path: locked readq updater: 1. sndseqossreset() or 1. A reader or callback producer release reaches takes q->lock on the same queue. sndseqossreadqclear(). 2. sndseqossreadqclear() 2. The updater tests or modifies resets qlen, head, tail, qlen, head, and tail. and inputtime. 3. sndseqossreadqclear() 3. The updater completes its wakes sleepers on read-modify-write sequence. q->midisleep. 4. Without q->lock, the reset 4. The resulting ring state drives can overlap the locked later reads and readiness. update.
KCSAN reports:
BUG: KCSAN: data-race in sndseqossreadqclear / sndseqossreadqfree
write to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0: sndseqossreadqfree+0x6c/0x80 sndseqossread+0xcb/0x250 odevread+0x38/0x60 vfsread+0xff/0x600 ksysread+0xb4/0x140 x64sysread+0x46/0x60 dosyscall64+0xbb/0x2f0 entrySYSCALL64afterhwframe+0x77/0x7f
read to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1: sndseqossreadqclear+0x1f/0x90 sndseqossreset+0xa7/0xf0 sndseqossioctl+0x6f6/0x7e0 odevioctl+0x56/0xc0 x64sysioctl+0xd1/0x120 dosyscall64+0xbb/0x2f0 entrySYSCALL64afterhwframe+0x77/0x7f
value changed: 0x00000001 -> 0x00000000
Affected Software
Event History
Frequently Asked Questions
Which systems can encounter this race condition?
Systems using the ALSA sequencer OSS read queue can encounter it when a queue reset runs concurrently with a reader, callback producer, or queue-free path operating on the same queue.
What symptoms can the race cause?
The queue can retain stale records, discard newly queued records, or report incorrect readiness after a wakeup. KCSAN detected a race between the queue-clear and queue-free paths.
What concurrency condition should be checked when assessing exposure?
The relevant condition is a reset path reaching snd_seq_oss_readq_clear() while another path holds the queue lock and reads or modifies the queue length, head, tail, or timestamp suppression state.