CVE-2026-89979 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix race between non-atomic ops and trigger-start
We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning).
There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition.
This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel’s Advanced Linux Sound Architecture subsystem contains a concurrency vulnerability related to race conditions between atomic and non-atomic operations on Pulse Code Modulation streams. Specifically, while protections exist for concurrent state transitions among atomic PCM operations, the synchronization mechanisms guarding against conflicts with non-atomic operations such as hardware parameter configuration, resource release, and stream preparation are insufficient. This gap allows scenarios where a thread may initiate or re-initiate prepare or hw_params calls on an already prepared stream at the exact moment another thread triggers the PCM start operation. Although these race conditions typically do not result in catastrophic system failures, they can lead to internal state inconsistencies that trigger kernel debugging warnings, such as ODEBUG errors reported by automated fuzzing tools like syzkaller.
The core of the issue lies in the timing and state management during stream initialization. The pcm_start function operates from the PREPARED state, making it particularly susceptible to interference if non-atomic setup operations are still in progress or being re-evaluated concurrently. Other trigger commands such as stop operate on different states like RUNNING and include pre-condition checks that effectively filter out conflicting concurrent access. However, the start command lacked a robust mechanism to verify whether non-atomic buffer access was currently underway. This oversight permitted overlapping execution paths where one thread modifies hardware parameters or prepares buffers while another simultaneously attempts to start audio playback, leading to undefined behavior within the kernel’s sound subsystem state machine.
To resolve this vulnerability, the fix leverages an existing synchronization primitive already utilized by hw_params, hw_free, and prepare operations: snd_pcm_buffer_access_lock. This lock mechanism sets a runtime flag indicating buffer access status. The patch modifies the PCM trigger-start logic to check the value of runtime->buffer_accessing before proceeding with the start operation. If this value is negative, it signifies that non-atomic PCM operations are currently active or in progress. By refusing to initiate the stream start under these conditions, the kernel ensures that atomic state transitions only occur when the buffer access context is stable and uncontested. This approach effectively serializes conflicting operations without requiring significant architectural changes to the existing locking hierarchy.
From a security perspective, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization. The race condition allows multiple execution contexts to interact with shared kernel data structures in an unsafe manner, potentially leading to state corruption or denial of service through system instability. In terms of the MITRE ATT&CK framework for enterprise environments, this type of vulnerability could be exploited as part of a privilege escalation chain if an attacker can trigger these race conditions from an unprivileged context, although it is primarily classified under Defense Evasion or Impact categories depending on whether the inconsistency leads to information disclosure or system crash. The mitigation involves ensuring strict serialization of buffer access during critical state transitions, thereby eliminating the window for concurrent modification attacks.
Administrators and developers should ensure that their Linux kernels are updated with patches addressing this specific ALSA PCM race condition. Since the vulnerability affects core audio subsystem functionality, it is particularly relevant in environments where high-concurrency audio processing occurs or when using applications that frequently reconfigure stream parameters while maintaining active connections. Regular kernel updates and adherence to best practices for handling asynchronous hardware operations will mitigate risks associated with similar synchronization flaws in other subsystems as well.