Cloudanix VulnDB

CVE-2026-68200

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux sound system lets a logged-in user trigger a memory error that can crash the whole computer or take it over.

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

What it actually does

Race condition in ALSA snd_timer allows concurrent snd_timer_interrupt calls on the same utimer instance; the SNDRV_TIMER_IFLG_CALLBACK bit cannot serialize multiple callbacks, so snd_timer_close_locked frees the instance and callback_data while a second callback is still executing, producing a use-after-free.

Why it matters to the business

Local attackers on affected Linux systems can crash the kernel or execute arbitrary code with kernel privileges, leading to full host compromise, data loss, or denial of service on any machine exposing /dev/snd/timer.

How an attack unfolds

An attacker opens /dev/snd/timer (or a sequencer queue bound to a utimer), then uses multiple threads to issue TRIGGER ioctls that invoke snd_timer_interrupt without serialization; the second interrupt re-queues the instance while its callback is still running, the first callback clears the flag, and close-path draining frees live callback_data.

How to fix it

Apply the upstream ALSA timer fix that skips re-queuing instances whose callback is still in flight; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Confirm the kernel source contains the check that skips re-queuing while SNDRV_TIMER_IFLG_CALLBACK is set; run the snd_timer stress tests exercising concurrent TRIGGER ioctls from multiple threads and verify no use-after-free or kernel oops occurs.

Typical attack path

  1. Obtain local shell on target Linux host
  2. Open /dev/snd/timer or create sequencer queue timer
  3. Spawn multiple threads that concurrently issue TRIGGER ioctls on the same timer instance
  4. Trigger the race so one callback runs while another re-queues and close-path frees the instance
  5. Use the resulting UAF to corrupt kernel memory and escalate privileges

How to detect it

Inspect kernel logs for oops/panic traces mentioning snd_timer, snd_timer_interrupt, or use-after-free in timer callback paths; correlate with processes that opened /dev/snd/timer or used ALSA sequencer interfaces around the crash time.

What your security team should do

  • Prioritize kernel updates on all multi-user or exposed Linux systems within the next patch cycle
  • Restrict access to /dev/snd/timer via device node permissions or SELinux/AppArmor policy where feasible
  • Monitor for kernel oops or panic logs referencing snd_timer_process_callbacks or snd_timer_close_locked
  • Audit systems that rely on ALSA sequencer or userspace timers for additional hardening

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.

Affected packages

Ecosystem Package Introduced Fixed