CVE-2026-80968

What it actually does

The ALSA mts64 kernel driver fails to reject a negative sound-card index during probe (commonly supplied as an invalid or “none” id when the device is bound through sysfs). That value is then used to index arrays and related per-card parameters, producing an out-of-bounds kernel memory access. Depending on how the invalid index is used, the result is kernel memory corruption (read and/or write), which can crash the host or, in a worst case, be turned into arbitrary kernel memory access. The defect is confined to the mts64 (ESI Miditerminal-class MIDI) driver path and requires the driver to be probed with a crafted index.

Why it matters to the business

Operational risk is concentrated on Linux systems that load the mts64 ALSA driver. A successful trigger can take the machine down (kernel oops/panic) or, if memory corruption is controlled, undermine kernel integrity and enable local privilege escalation. The driver is niche (parallel-port MIDI hardware), exploit maturity is none, EPSS is very low and flat (~0.0022 over 30 days), and the CVE is not in CISA KEV and is not associated with ransomware. Urgency is therefore moderate-to-low for general estates and higher only where this module is present, unprivileged users can bind drivers via sysfs, or kernel hardening is weak. No downstream package-prevalence data was supplied.

How an attack unfolds

An attacker who already has local code execution (or the ability to write to the relevant sysfs bind/unbind and module-parameter interfaces) causes the mts64 driver to probe with a negative or otherwise out-of-range card index. The probe path skips a lower-bound check, indexes kernel arrays with that value, and performs an out-of-bounds access. The attacker then relies on the resulting kernel memory corruption: an uncontrolled access typically panics or oopses the kernel (denial of service); a more careful layout may overwrite adjacent kernel objects. No named threat actors, in-the-wild campaigns, or public exploit maturity are associated with this CVE. Exploitation is local, hardware/driver-specific, and not a remote unauthenticated attack.

How to fix it

Apply the Linux kernel update that adds a card-index sanity check in the ALSA mts64 probe path (reject/warn/correct out-of-range, including negative, ids). Consume the patched kernel from your distribution or upstream stable tree as soon as it is available; exact per-package fixed versions were not provided with this record, so track distro security advisories for CVE-2026-80968 / the mts64 probe fix. If you cannot patch immediately: blacklist or unload snd-mts64 where the MIDI hardware is not required; restrict unprivileged sysfs driver bind/unbind and module loading (lock down /sys/bus/*/drivers/*/bind, module parameters, and CAP_SYS_MODULE); and ensure only trusted administrators can attach this driver. Do not leave development-style sysfs binding exposed on production hosts.

How to confirm the fix worked

Confirm the running kernel includes the mts64 card-index validity check (probe rejects or corrects negative/out-of-range ids and does not index arrays with them). Verify the installed kernel package changelog or git commit for the ALSA mts64 probe fix, and that snd-mts64 matches the patched build. On systems that should not use this hardware, confirm the module is blacklisted and not loaded (lsmod / /proc/modules). Review whether unprivileged users can bind drivers through sysfs. Do not attempt to reproduce the out-of-bounds access on production; validation is presence of the patched kernel and absence of an unpatched mts64 probe path.

Typical attack path

1. Obtain local access on a Linux host where the ALSA mts64 driver can be loaded or bound.
2. Ensure the mts64 driver is available (module present or built-in) and that the attacker can influence probe-time card index / device id, typically via sysfs bind or equivalent module parameters.
3. Supply a negative or otherwise out-of-range card index so the probe path indexes per-card arrays without a lower-bound check.
4. Trigger probe; the kernel performs an out-of-bounds access against index[] and related parameters.
5. Use the resulting memory corruption to crash the kernel or, if the corruption is controllable, to interfere with kernel state for local privilege escalation or persistence.
6. No remote initial-access stage is implied; follow-on impact stays on the same host.

How to detect it

There are no public in-the-wild exploits, named actors, or KEV associations, so hunting is for suspicious local driver bind/probe activity rather than a known campaign. Review kernel logs (dmesg, journalctl -k, /var/log/kern.log) around mts64 / snd-mts64 probe, ALSA card registration, and any oops/panic with mts64 frames. Audit auditd/syscalls and systemd-journal for unexpected writes to sysfs driver bind/unbind and for insmod/modprobe of snd-mts64, especially from non-admin users or at odd times. Check whether the module was loaded on hosts without the corresponding MIDI hardware. Kernel crash dumps (kdump/vmcore) with RIP/call traces in the mts64 probe path are the strongest post-exploitation artifact. Negative or huge card index values in ALSA/module parameter logs, if logged, are suspicious. Absence of these signals does not prove the bug was never hit; it is a local, low-visibility condition.

• snd-mts64
• mts64_probe
• ALSA: mts64
• modprobe snd-mts64
• insmod snd-mts64
• /sys/bus/parport/drivers/
• /sys/module/snd_mts64
• index[]
• Oops:.*mts64
• BUG:.*mts64

What your security team should do

• Inventory Linux hosts for snd-mts64 / mts64 (loaded module, initramfs, or kernel config) and prioritize those images for kernel upgrade.
• Patch to a kernel that contains the ALSA mts64 card-index sanity check; do not wait on KEV or EPSS given this is a kernel memory-corruption class bug, but deprioritize relative to remotely wormable KEVs.
• Where the driver is unused, blacklist snd-mts64 and restrict sysfs driver bind and module load to administrators.
• Treat as local-only: pair with standard local-privilege-escalation hardening (unprivileged userns, module autoload limits, locked-down sysfs).
• Monitor distro advisories for the exact package version; re-scan after rollout to confirm the vulnerable module build is gone.
• No evidence of in-the-wild or ransomware use; do not declare incident solely from publication.