CVE-2026-80628
nicheRace condition in Linux kernel ALSA OSS sequencer emulation
CVE-2026-80628 is a race condition in the Linux kernel's ALSA OSS sequencer emulation (snd-seq-oss), where snd_seq_oss_readq_clear() resets the read-queue state (qlen, head, tail and input_time) without holding the queue's q->lock spinlock that all other readers and producers use to serialize access. It is triggered when a queue reset, such as snd_seq_oss_reset() reached via an OSS sequencer ioctl or device release, runs concurrently with a reader (snd_seq_oss_readq_free()) or event producer (snd_seq_oss_readq_put_event()) on the same queue; a KCSAN data-race report between snd_seq_oss_readq_clear and snd_seq_oss_readq_free demonstrates the defect. A local, low-privileged user able to use the OSS sequencer device could induce or observe corrupted queue state, leaving stale records in the queue, dropping freshly queued events, or reporting incorrect readiness after wakeup, and the CVSS 3.1 score of 7.8 (high) rates the potential confidentiality, integrity and availability impact as high. Any Linux kernel with the ALSA OSS sequencer emulation enabled is affected in principle, but practical exposure is limited because the legacy /dev/sequencer interface is rarely used on modern systems. No public proof-of-concept, KEV listing, or in-the-wild exploitation is currently known; EPSS is 0.1% (3rd percentile).
What to do: Install a kernel update that includes the 'ALSA: seq: oss: Serialize readq reset state with q->lock' fix as soon as your distribution ships it; no fixed version number is specified in the available data, so track your vendor's advisory for the exact package version. To assess whether you are exposed, check whether the snd-seq-oss module is loaded (e.g., lsmod) and whether local users or services access /dev/sequencer; restricting that device node to trusted local users is a reasonable interim mitigation.
| Linux kernel (ALSA sequencer OSS emulation, snd-seq-oss) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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: 1. snd_seq_oss_reset() or 1. A reader or callback producer release reaches takes q->lock on the same queue. snd_seq_oss_readq_clear(). 2. snd_seq_oss_readq_clear() 2. The updater tests or modifies resets qlen, head, tail, qlen, head, and tail. and input_time. 3. snd_seq_oss_readq_clear() 3. The updater completes its wakes sleepers on read-modify-write sequence. q->midi_sleep. 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 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
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.