CVE-2026-98314

ALSA: pcm: set timer->private_data before registering the PCM timer

N/A
Published: October 6, 2026 at 08:46 AM UTC
Updated: October 19, 2026 at 10:18 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: set timer->private_data before registering the PCM timer snd_pcm_timer_init() calls snd_device_register() to link the new struct snd_timer into the global timer list while it still carries hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop), and only afterwards sets timer->private_data = substream. Once the timer is on the list under register_mutex, a concurrent reader can already reach it through the same mutex and invoke these callbacks. /proc/asound/timers does this via c_resolution(), and snd_timer_open()+snd_timer_start() reach start()/stop() the same way. All three dereference timer->private_data, which for this brief window is NULL, giving a NULL-pointer dereference: substream = timer->private_data; return substream->runtime ? ... // substream is NULL Move the private_data/private_free assignment before snd_device_register() so the timer is never visible on the list without its private_data set. On the snd_device_register() failure path, private_free() (snd_pcm_timer_free()) can now run, but it only does substream->timer = NULL, which is already NULL at that point since substream->timer is set to the new timer just once, after a successful registration -- so the failure path stays safe.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

Vendor states this is fixed in 2.6.12 (unaffected)
Vendor states this is fixed in 5.10.* (unaffected)
Vendor states this is fixed in 5.10.271 (unaffected)
Vendor states this is fixed in 5.15.* (unaffected)
Vendor states this is fixed in 5.15.222 (unaffected)
Vendor states this is fixed in 6.1.* (unaffected)
Vendor states this is fixed in 6.1.189 (unaffected)
Vendor states this is fixed in 6.12.* (unaffected)
Vendor states this is fixed in 6.12.112 (unaffected)
Vendor states this is fixed in 6.18.* (unaffected)
Vendor states this is fixed in 6.18.54 (unaffected)
Vendor states this is fixed in 6.6.* (unaffected)
Vendor states this is fixed in 6.6.158 (unaffected)
Vendor states this is fixed in 7.2.* (unaffected)
Vendor states this is fixed in 7.2.8 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card