Skip to main content
VulnerabilityPublished Updated

CVE-2026-53193: Linux kernel · ALSA: timer: Forcibly close timer instances at closing

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in f46093dd22969037beb1fce2e043f3236be41c92 : patch Linux kernel soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in f46093dd22969037beb1fce2e043f3236be41c92, da3039e91d1f835874ed6e9a33ea19ee80c2cb92, 586b219a22b1032b28b8bd356b963276c5e5bf53 +1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 25 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to f46093dd22969037beb1fce2e043f3236be41c92, da3039e91d1f835874ed6e9a33ea19ee80c2cb92, 586b219a22b1032b28b8bd356b963276c5e5bf53 or 60e73ab87b84bbd6bd7ddd1d16019a3a3705ab8f.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 37745918e0e7575bc40f38da93a99b9fa6406224, < f46093dd22969037beb1fce2e043f3236be41c92
Fixed in
  • f46093dd22969037beb1fce2e043f3236be41c92
LinuxLinuxAffected
  • ≥ 37745918e0e7575bc40f38da93a99b9fa6406224, < da3039e91d1f835874ed6e9a33ea19ee80c2cb92
Fixed in
  • da3039e91d1f835874ed6e9a33ea19ee80c2cb92
LinuxLinuxAffected
  • ≥ 37745918e0e7575bc40f38da93a99b9fa6406224, < 586b219a22b1032b28b8bd356b963276c5e5bf53
Fixed in
  • 586b219a22b1032b28b8bd356b963276c5e5bf53
LinuxLinuxAffected
  • ≥ 37745918e0e7575bc40f38da93a99b9fa6406224, < 60e73ab87b84bbd6bd7ddd1d16019a3a3705ab8f
Fixed in
  • 60e73ab87b84bbd6bd7ddd1d16019a3a3705ab8f
LinuxLinuxAffected
  • =6.12
Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Forcibly close timer instances at closing When snd_timer object is freed via snd_timer_free() and still pending snd_timer_instance objects are assigned to the timer object, it tries to unlink all instances and just set NULL to each ti->timer, then releases the resources immediately. The problem is, however, when there are slave timer instances that are associated with a master instance linked to this timer: namely, those slave instances still point to the freed timer object although the master instance is unlinked, which may lead to user-after-free. The bug can be easily triggered particularly when a new userspace-driven timers (CONFIG_SND_UTIMER) is involved, since it can create and delete the timer object via a simple file open/close, while the other applications may keep accessing to that timer. This patch is an attempt to paper over the problem above: now instead of just unlinking, call snd_timer_close[_locked]() forcibly for each pending timer instance, so that all assigned slave timer instances are properly detached, too. Since snd_timer_close() might be called later by the driver that created that instance, the check of SNDRV_TIMER_IFLG_DEAD is added at the beginning, too.

References

Community reviews

Loading reviews…