Cloudanix VulnDB

CVE-2026-80969

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux sound driver can crash the computer if it is attached with an invalid device number, so install the kernel update that checks that number first.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The ALSA mpu401 MIDI UART driver trusted an unchecked device card index at probe and could index kernel arrays such as index[] and related parameter tables out of bounds when that index was invalid (for example -1 when a device is bound manually). The result is kernel out-of-bounds memory access in a MemoryCorruption-class bug, typically a kernel oops or panic and, in principle, further kernel memory corruption if the out-of-range access is controllable.

Why it matters to the business

Hosts that load the legacy ALSA mpu401 driver may crash or become unstable if the driver is probed with an invalid card index, interrupting MIDI/audio services and often requiring a reboot. This issue is not in CISA KEV, is not associated with ransomware, has no public exploit maturity, and has a very low, flat EPSS (~0.22% over 30 days). Operational urgency is therefore modest and mainly applies to Linux systems that still use this MIDI UART driver; treat it as a routine kernel memory-safety fix rather than an emergency internet-facing incident.

How an attack unfolds

No in-the-wild exploitation or named threat actors are associated with this issue. A local actor who can bind kernel drivers would need to cause the mpu401 driver to probe with a card index outside the valid range so that the driver performs an out-of-bounds array access. Binding via the sysfs driver interface is the condition described in the fix; that capability is normally limited to highly privileged local users. With no known exploit code, the realistic outcome is a kernel oops or denial of service rather than reliable privilege escalation.

How to fix it

Install a Linux kernel update from your distribution or vendor that includes the upstream ALSA change 'ALSA: mpu401: Check card index validity at probe', which validates the card index at probe and warns or corrects out-of-range values. If a patched kernel is not yet available, avoid loading snd-mpu401 / snd-mpu401-uart where MIDI UART hardware is not required, and restrict who can bind kernel drivers. Reboot into the patched kernel so the updated module is actually running. No specific upstream version numbers were provided with this record; track your distro kernel changelog for that ALSA mpu401 probe check.

How to confirm the fix worked

Confirm the running kernel changelog or package notes include the mpu401 card-index validity check at probe. After reboot, verify the loaded snd-mpu401 / snd-mpu401-uart module matches the patched kernel, and that sound/MIDI devices still initialize normally. Review dmesg/journal for ALSA mpu401 warnings about an out-of-range card index, which indicate the new sanity check is present and firing rather than a silent OOB access. On hosts that do not need the driver, confirm it is not loaded and is blacklisted if that is the chosen mitigation.

Typical attack path

  1. Gain local access on a Linux host that can load the ALSA mpu401 driver
  2. Obtain privileges sufficient to bind or instantiate that driver with a non-default device identity
  3. Cause probe with a card index outside the valid range (invalid or sentinel identity)
  4. Trigger out-of-bounds access of kernel card-index and parameter arrays
  5. Induce a kernel oops, panic, or other memory-corruption side effect

How to detect it

There is no evidence of in-the-wild exploitation and no attributed actors, so hunting should focus on whether the vulnerable probe path was exercised rather than on a known campaign. Review kernel logs (dmesg, journalctl -k, crash dumps, pstore) around mpu401 probe for oops/panic call traces involving ALSA mpu401 functions, and for any new warnings about an invalid card index after the fix is applied. Correlate those events with privileged local activity that binds or instantiates the mpu401 UART driver. Absence of such logs does not prove the host was never exposed; it only indicates no observed crash or warning from this driver.

  • snd-mpu401-uart
  • snd_mpu401
  • mpu401_probe
  • ALSA: mpu401

What your security team should do

  • Patch and reboot Linux kernels to a build that includes the ALSA mpu401 card-index probe check; this is the primary fix.
  • Inventory where snd-mpu401 / snd-mpu401-uart is loaded and unload or blacklist it on systems that do not use MIDI UART hardware.
  • Keep this below emergency KEV-style priority: EPSS is very low, exploit maturity is none, and it is not listed for ransomware, but do not skip it in the next kernel maintenance window because it is kernel memory corruption.
  • Limit and audit privileged local operations that bind kernel drivers so untrusted users cannot force probe of legacy ALSA drivers.
  • Watch vendor kernel advisories for the exact package versions that carry this fix, since no fixed-version list was supplied with the CVE record.

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

Affected packages

Ecosystem Package Introduced Fixed