Cloudanix VulnDB

CVE-2026-80628

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Aug 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux sound system allows two parts of the code to change the same internal list at the same time without proper coordination, which can cause sound features to behave incorrectly or crash on affected machines.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Data race in ALSA sequencer OSS read queue where snd_seq_oss_readq_clear resets qlen/head/tail/input_time without holding q->lock, allowing concurrent modification by snd_seq_oss_readq_free, snd_seq_oss_readq_put_event, or snd_seq_oss_readq_put_timestamp and resulting in stale queue entries, dropped events, or incorrect readiness state.

Why it matters to the business

Local users on affected Linux systems can trigger audio/sequencer subsystem instability or corruption, potentially leading to application crashes or denial of service in sound-related workloads; low public exploitability reduces immediate enterprise risk but still requires prompt kernel updates on exposed systems.

How an attack unfolds

A local attacker invokes snd_seq_oss_reset or release paths that call clear while a concurrent reader or producer holds the lock and performs read-modify-write on the same ring state; the unprotected reset overlaps the locked update, leaving inconsistent queue metadata that can be leveraged for further local impact.

How to fix it

Apply the upstream Linux kernel commit that serializes snd_seq_oss_readq_clear under q->lock and factors enqueue logic into a locked helper; rebuild and reboot to the patched kernel; monitor for backports in distribution kernels.

How to confirm the fix worked

Confirm the fix by inspecting the snd_seq_oss.c source for q->lock acquisition around the qlen/head/tail reset and input_time update; re-run KCSAN on the OSS sequencer paths and verify absence of the reported data race; test concurrent reset and read/produce operations for consistent queue state.

Typical attack path

  1. Obtain local user access on a Linux system using ALSA OSS sequencer
  2. Trigger snd_seq_oss_ioctl or reset paths that invoke readq_clear
  3. Simultaneously exercise read or event-producer paths under q->lock
  4. Observe resulting stale or corrupted queue state for follow-on abuse

How to detect it

Search kernel logs and dmesg for KCSAN data-race reports referencing snd_seq_oss_readq_clear and snd_seq_oss_readq_free; inspect stack traces containing snd_seq_oss_reset, snd_seq_oss_ioctl, and odev_read/odev_ioctl; monitor for unexpected sequencer queue resets or lost MIDI events in application logs.

  • BUG: KCSAN: data-race in snd_seq_oss_readq_clear / snd_seq_oss_readq_free
  • snd_seq_oss_readq_clear+0x1f/0x90
  • snd_seq_oss_readq_free+0x6c/0x80
  • write to .* of 4 bytes by task .* on cpu .* snd_seq_oss_readq_free
  • read to .* of 4 bytes by task .* on cpu .* snd_seq_oss_readq_clear

What your security team should do

  • Prioritize kernel updates on multi-user or audio-processing systems within standard patch windows
  • Restrict untrusted local accounts from accessing /dev/sequencer or OSS device nodes where feasible
  • Enable KCSAN or similar concurrency checkers in internal kernel CI builds
  • Review ALSA/OSS usage in production workloads for unnecessary exposure

The record

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

Affected packages

Ecosystem Package Introduced Fixed