CVE-2026-80628

In the Linux kernel, the following vulnerability has been resolved:

ALSA: seq: oss: Serialize readq reset state with q->lock

snd seq oss readq clear() 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 snd seq oss readq free() or snd seq oss readq put event() and leave stale records in the queue, drop freshly queued ones, or report the wrong readiness after wakeup. KCSAN reports a data race between snd seq oss readq clear() and snd seq oss readq free().

Take q->lock while clearing the ring and resetting input time. Factor the enqueue logic into a caller-locked helper so snd seq oss readq put timestamp() 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:

KCSAN reports:

BUG: KCSAN: data-race in snd seq oss readq clear / snd seq oss readq free

write to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0: snd seq oss readq free+0x6c/0x80 snd seq oss read+0xcb/0x250 odev read+0x38/0x60 vfs read+0xff/0x600 ksys read+0xb4/0x140 x64 sys read+0x46/0x60 do syscall 64+0xbb/0x2f0 entry SYSCALL 64 after hwframe+0x77/0x7f

read to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1: snd seq oss readq clear+0x1f/0x90 snd seq oss reset+0xa7/0xf0 snd seq oss ioctl+0x6f6/0x7e0 odev ioctl+0x56/0xc0 x64 sys ioctl+0xd1/0x120 do syscall 64+0xbb/0x2f0 entry SYSCALL 64 after hwframe+0x77/0x7f

value changed: 0x00000001 -> 0x00000000