Description

In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: wake linked drain waiters on unlink snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:57.303Z",
  "pubdate": "2026-08-28T08:16:57.303Z",
  "executiveSummary": "This vulnerability is a use-after-free defect within the Linux kernel's Advanced Linux Sound Architecture (ALSA) PCM subsystem, specifically affecting linked PCM streams.\nThe flaw occurs during the PCM drain process when a stream's group membership is modified while a thread is blocked waiting for drain completion.\nThe vulnerability allows for memory corruption as a wait queue entry residing on the stack of a caller may remain linked to a stream's sleep list after the stack frame has been destroyed.\nSuccessful exploitation requires the ability to manipulate PCM stream linking and trigger race conditions through unlinking operations during a drain sequence.\nThe potential impact includes kernel-level arbitrary code execution, local privilege escalation, or system crashes due to the dereferencing of invalid memory pointers during wake-up events.\nThis issue represents a significant security risk to any Linux system leveraging linked PCM streams, as it facilitates a use-after-free scenario when `wake_up()` attempts to traverse a corrupted wait queue list referencing freed stack memory.",
  "technicalDetails": "The vulnerability resides in the interaction between `snd_pcm_drain()` and `snd_pcm_unlink()`. In the ALSA PCM implementation, linked streams share wait queues for synchronization. When a process calls `snd_pcm_drain()` on a linked stream, it creates a wait entry on the thread's stack and inserts it into the `runtime->sleep` queue of the peer stream. Historically, the code relied on `snd_pcm_link_rwsem` to ensure group integrity; however, the removal of this lock and the subsequent transition to conditional removal logic created a race condition.\nThe root cause is the conditional removal of wait entries. The current logic only removes the wait entry if the peer stream remains part of the caller's group after `schedule_timeout()` returns. If the process is interrupted by a signal or the timer expires before the lock is reacquired, the wait entry remains in the queue. Because the cleanup logic is skipped, the stack-based entry persists in the kernel's wait list.\nWhen a stream is unlinked via `snd_pcm_unlink()`, the system fails to perform a necessary wake-up call to release these queued threads. Consequently, the wait queue maintains a reference to a stack frame that is no longer valid once the `snd_pcm_drain()` function returns. A subsequent attempt to wake the queue—or any operation that traverses the linked list of wait entries—will trigger a use-after-free, as the kernel attempts to access the memory location of the stale wait entry.\nThe attack flow follows these steps: 1) The attacker initiates a linked PCM drain, causing the kernel to append a stack-allocated entry to the sleep list. 2) The attacker triggers an unlink operation or forces a signal-based exit from the wait state. 3) Due to the lack of explicit wake-up or removal during unlinking, the wait list pointer persists. 4) The stack frame is reused or deallocated. 5) A later event (such as another PCM state change) triggers a `wake_up()` call, which traverses the wait list, dereferences the invalid pointer in the freed stack, and results in a kernel panic or potential memory corruption.\nThis vulnerability does not strictly require network exposure, as it is a local kernel interface issue. However, any local user with permissions to interact with ALSA PCM devices (`/dev/snd/pcm*`) can potentially trigger this race condition."
}