Description

In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Clear SNDRV_TIMER_IFLG_DEAD once the close completes snd_timer_close_locked() marks an instance with SNDRV_TIMER_IFLG_DEAD and returns early when the flag is already set, but the flag is never cleared again. A completed close ends in remove_slave_links(), which leaves timeri->timer NULL, so a second close is already harmless through the timer == NULL path; the early return can only be reached by an instance that was opened again in between. For such an instance the close unlinks nothing, so snd_timer_instance_free() frees an object that is still on timer->open_list_head, still on snd_timer_master_list if it was opened with a slave key, still owns any adopted slaves, and still holds its timer and module references. snd_seq_timer_open() reopens an instance exactly like that: it retries its fallback open on the same object after a failure that has already run snd_timer_close_locked() internally. An unprivileged user with access to /dev/snd/timer and /dev/snd/seq can force that failure, since snd_timer_check_master() returns -EBUSY when a pending slave matches the new master's (slave_class, slave_id) key and the target timer has reached max_instances, and SNDRV_TIMER_IOCTL_SELECT with dev_class = SNDRV_TIMER_CLASS_SLAVE keeps the caller-supplied dev_sclass, so a sequencer queue's key can be forged. The freed instance is afterwards dereferenced by any further snd_timer_open() on that timer, by snd_timer_check_slave(), and by /proc/asound/timers, which faults on the stale ti->owner pointer. The flag only has to be visible while the close is in progress, which is all its other users need. Clear it in remove_slave_links(), under the same timer->lock that sets it, once the instance is off every list.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:55.310Z",
  "pubdate": "2026-08-15T13:17:55.310Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel ALSA timer component, specifically within the timer instance closing and reopening logic. The flaw arises because the SNDRV_TIMER_IFLG_DEAD flag is set during snd_timer_close_locked() to mark an instance as dead, but it is never cleared upon completion. If an instance is reopened via mechanisms such as snd_seq_timer_open() following a failed open attempt, a subsequent close operation can prematurely free a timer instance that remains linked to internal lists and reference structures. Unprivileged local attackers with access to /dev/snd/timer and /dev/snd/seq can trigger this condition by forging sequencer queue keys and causing fallback open failures under specific race or error states. Successful exploitation leads to memory corruption, kernel panics, or potential local privilege escalation through the dereference of stale pointers during subsequent timer operations, checks, or reads of /proc/asound/timers.",
  "technicalDetails": "The vulnerability resides in the ALSA timer subsystem of the Linux kernel, specifically affecting timer instance lifecycle management functions including snd_timer_close_locked(), remove_slave_links(), snd_timer_instance_free(), and snd_seq_timer_open(). The root cause is the persistent state of the SNDRV_TIMER_IFLG_DEAD flag. When snd_timer_close_locked() executes, it flags the timer instance with SNDRV_TIMER_IFLG_DEAD and returns early if the flag is already set. However, this flag is never cleared once the close sequence completes.\nUnder normal execution, a completed close terminates in remove_slave_links(), which nullifies timeri->timer. However, if an instance is opened again in between closes, an early return path is triggered. For such an instance, the close operation fails to unlink the object properly. Consequently, snd_timer_instance_free() frees an object that is still linked on timer->open_list_head, still present on snd_timer_master_list if opened with a slave key, still retains ownership of adopted slaves, and continues to hold active timer and module references.\nAn unprivileged user with access to /dev/snd/timer and /dev/snd/seq can orchestrate this state. Specifically, snd_seq_timer_open() retries its fallback open on the same object following a failure that internally executed snd_timer_close_locked(). An attacker can force this failure scenario because snd_timer_check_master() returns -EBUSY when a pending slave matches the new master's (slave_class, slave_id) key and the target timer has reached max_instances. Furthermore, issuing SNDRV_TIMER_IOCTL_SELECT with dev_class set to SNDRV_TIMER_CLASS_SLAVE preserves the caller-supplied dev_sclass, enabling the forgery of a sequencer queue's key.\nOnce the timer instance is prematurely freed while still referenced internally, subsequent operations result in severe memory safety violations. The freed instance is subsequently dereferenced during any further snd_timer_open() calls on that timer, by snd_timer_check_slave(), and when reading /proc/asound/timers, which faults upon encountering the stale ti->owner pointer. Attackers can leverage this use-after-free condition to crash the kernel or potentially achieve arbitrary code execution depending on heap layout and kernel mitigations."
}