Description

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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:47.007Z",
  "pubdate": "2026-08-28T08:16:47.007Z",
  "executiveSummary": "A race condition vulnerability exists in the ALSA sequencer OSS emulation layer within the Linux kernel.\nThe vulnerability arises from the improper synchronization of ring buffer state variables, specifically qlen, head, and tail, within the snd_seq_oss_readq_clear function.\nThe flaw allows concurrent execution of queue modification and reset operations, leading to data corruption or inconsistent internal state tracking.\nSuccessful exploitation could result in stale record retention, loss of event data, or incorrect scheduling readiness notifications.\nThe impact is primarily localized to the ALSA sequencer subsystem, potentially leading to kernel-level memory inconsistencies or denial-of-service conditions if an attacker triggers frequent race-prone ioctl sequences.\nExploitation requires local access to the system and the ability to interact with the /dev/sequencer device.\nNo specific privileges are required beyond standard user access to the sound device, though the race window is narrow, typically requiring specific thread scheduling and high-frequency syscall activity.",
  "technicalDetails": "The root cause of this vulnerability is the lack of spinlock protection (q->lock) during the reset operations performed by snd_seq_oss_readq_clear().\nIn the Linux kernel's ALSA OSS sequencer implementation, ring buffer operations are expected to be atomic regarding the queue's state variables (qlen, head, and tail). While most paths, such as snd_seq_oss_readq_put_event(), correctly acquire q->lock to perform these modifications, the reset path executes without this synchronization primitive.\nThe vulnerability manifests as a data race between two primary execution paths: the 'reset path', which triggers snd_seq_oss_readq_clear(), and the 'updater path', which includes reading, producing, or freeing queue events. Because snd_seq_oss_readq_clear() modifies the internal ring indices while another CPU may be executing a read or free operation, the kernel experiences a classic TOCTOU (Time-of-Check to Time-of-Use) scenario.\nStep-by-step exploitation flow:\n1. An attacker initiates an ioctl call that triggers snd_seq_oss_reset(), eventually calling the unsynchronized snd_seq_oss_readq_clear().\n2. Simultaneously, a separate thread invokes a standard file operation (read or close) on the sequencer device, which enters a path (e.g., snd_seq_oss_readq_free) that attempts to modify or query the queue state.\n3. On one CPU, the reset operation begins updating the qlen and tail indices. On another CPU, the updater path reads these partially updated or stale values while attempting to perform its own write sequence.\n4. Due to the absence of memory barriers and locking, the CPU cache consistency is bypassed, leading to an inconsistent state where the ring buffer structure no longer matches the tracked qlen.\n5. The mismatch results in the corruption of the MIDI event queue. This can lead to the kernel processing stale MIDI data (if stale records remain) or silent dropping of valid event data (if the indices are reset mid-write).\nThe KCSAN diagnostic highlights this specifically as a data race involving the 4-byte memory region representing the queue state. Without the locking implementation, the system cannot guarantee the integrity of the sequencer ring buffer, as the wakeup mechanisms (e.g., q->midi_sleep) rely on the consistency of the state that has just been altered in an uncontrolled manner."
}