Look up another CVE · open CVE-2026-80628 in the interactive tracker
CVE-2026-80628
ALSA: seq: oss: Serialize readq reset state with q->lock
Published 2026-08-28 (2 months ago) by the Linux kernel CNA. Subsystem sound/core. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-80628 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
sound/core/seq/oss/seq_oss_readq.c
- What this is
- SOUNDMAINTAINERS section matched on sound/ · linux-sound@vger.kernel.org · Maintained
- Kernel module
- none to look for. The file would have gone into snd_seq_oss, and Debian does not compile it into that module, so finding snd_seq_oss in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_SND|CONFIG_SND_SEQUENCER|CONFIG_SND_SEQUENCER_OSS' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code. In 4 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_SND, CONFIG_SND_SEQUENCER, CONFIG_SND_SEQUENCER_OSS
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-28 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- sound/core
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.12 | 6.18.40 | 287d506d4e08 |
| 2.6.12 | 7.1.5 | 43e10709b1ba |
| 2.6.12 | 7.2 | 49ce92d20782 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Exploitation requires local syscall access to OSS sequencer character devices (/dev/sequencer or /dev/music) via read(2), ioctl(SNDCTL_SEQ_RESET/SNDCTL_SEQ_PANIC), or release; there is no network, Bluetooth, or physical-bus path into snd_seq_oss_readq_clear().
- AC:LAttack complexity, low
- The attacker controls both race participants on the same fd (one thread ioctl reset or close while another read(2)s, or concurrent MIDI enqueue via sequencer callbacks) and can hammer the timing window without conditions outside attacker control.
- PR:LPrivileges required, low
- odev_open/read/ioctl perform no capability checks; desktop, studio, and kiosk systems routinely grant unprivileged users access to /dev/sequencer via audio group or logind ACLs, and attackers can create ALSA MIDI ports to satisfy open requirements.
- UI:NUser interaction, none
- Triggering the race requires only the attacker's own threads or processes opening the sequencer and issuing reset/read; no separate victim action such as plugging hardware, mounting filesystems, or opening files on behalf of another user.
- S:UScope, unchanged
- Corruption is confined to the kernel OSS sequencer read queue within the same security domain; this is a standard local kernel memory-safety issue with no VM, IOMMU, or container-escape boundary crossed.
- C:HConfidentiality impact, high
- Unlocked snd_seq_oss_readq_clear() races locked dequeue/enqueue on qlen/head/tail, yielding inconsistent ring state that can drive snd_seq_oss_readq_pick() and copy_to_user() to return unintended queue slots and expose stale kernel heap contents.
- I:HIntegrity impact, high
- The same race corrupts ring indices and length while snd_seq_oss_readq_put_event_locked() memcpy-writes events, enabling out-of-sync overwrites within the kmalloc'd queue object that can be groomed toward arbitrary kernel memory modification.
- A:HAvailability impact, high
- Corrupted qlen/head/tail and wakeup state from the unlocked reset can strand readers in wait/poll loops and deny MIDI/audio input on kiosk, studio, and media systems; the KCSAN-proven race is attacker-repeatable via ioctl reset concurrent with read(2).