Cloudanix VulnDB

CVE-2026-68201

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux handles sound timers can let someone logged into the computer crash it or run unauthorized code.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Medium

What it actually does

Use-after-free in ALSA timer subsystem: closing a master timer instance frees slave instances while their callbacks may still be executing because remove_slave_links() severs the timer pointer before the slave drain logic runs.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel crashes or potentially execute arbitrary code, risking system stability and confidentiality on any machine using ALSA audio timers.

How an attack unfolds

An attacker with local access creates a master timer with attached slaves, triggers in-flight callbacks on the slaves, then closes the master; the missing drain for slaves leaves a live callback referencing freed memory, resulting in use-after-free.

How to fix it

Apply the upstream kernel patch that drains slave callbacks before remove_slave_links() severs them; rebuild and deploy the fixed kernel on all affected systems.

How to confirm the fix worked

Confirm the presence of the commit titled "ALSA: timer: drain a slave's callback before its master detaches it" in the running kernel source; test timer close sequences under load to verify no UAF occurs.

Typical attack path

  1. Obtain local user access on a Linux system with ALSA enabled
  2. Allocate a master timer instance and attach one or more slave timers
  3. Arrange for slave callbacks to be queued or in-flight (e.g., via snd_timer_start)
  4. Close the master timer instance while callbacks are still executing
  5. Trigger the use-after-free by accessing the now-freed slave structures

How to detect it

Inspect kernel logs for ALSA timer oops or use-after-free warnings during snd_timer_close paths; correlate with processes that open and rapidly close timer instances.

What your security team should do

  • Prioritize kernel updates on any system exposing ALSA to untrusted local users
  • Monitor for related ALSA timer crashes in kernel logs as an interim detection measure
  • Restrict local access to audio subsystems where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.

Affected packages

Ecosystem Package Introduced Fixed