CVE-2026-80965

What it actually does

The Linux kernel ALSA serial-u16550 driver does not validate the card index (device id) at probe. Self-created devices are in range, but a device bound manually through sysfs can carry id -1 (the “none” sentinel). That value is used to subscript the driver’s index[] and related parameter arrays, causing an out-of-bounds kernel memory access and possible memory corruption or crash.

Why it matters to the business

Real-world business risk is low. This is a local issue in a niche serial/UART MIDI ALSA driver, with EPSS 0.0022 (flat over 30 days), no KEV listing, no ransomware use, exploit maturity none, and no reported in-the-wild activity about 20 days after publication. The plausible operational impact is availability (kernel oops or panic) on hosts that load this driver—not remote breach or fleet-wide compromise. Raise priority only for multi-tenant or untrusted-local-user systems that actually use this module.

How an attack unfolds

This is not remotely exploitable and has no known public exploit or named threat-actor use. An attacker already on the host who can bind a kernel driver via sysfs could attach serial-u16550 with an out-of-range card index so probe treats that index as an array subscript and touches adjacent kernel memory. Binding drivers normally requires administrative privilege, so this is a weak local escalation primitive and is more likely to cause a denial of service than a reliable privilege gain.

How to fix it

Install the Linux distribution kernel update that includes the ALSA serial-u16550 probe-time card-index sanity check (upstream warns and corrects out-of-range indices). Exact package versions were not supplied with this record—use vendor advisories. If a patch is delayed: do not manually bind devices to this driver via sysfs, restrict bind/unbind sysfs to administrators, and unload/blacklist snd-serial-u16550 where serial UART ALSA is not required.

How to confirm the fix worked

Confirm the running kernel changelog or package includes the serial-u16550 card-index validity check. Inventory whether snd-serial-u16550 is loaded or shipped (lsmod, module tree). After patching, an out-of-range index should be warned on and corrected rather than used for array access; unpatched exposure is any host that can load this driver and allow sysfs bind.

Typical attack path

1. Obtain local access on a Linux host where the ALSA serial-u16550 driver is available
2. Obtain the ability to bind devices to kernel drivers through sysfs (typically a privileged capability)
3. Bind a device to serial-u16550 using a card index outside the valid range (including the “none” sentinel -1)
4. Probe uses that index against index[] and related parameter arrays, causing out-of-bounds kernel memory access
5. Outcome is typically a kernel oops/panic (denial of service); memory corruption could theoretically be abused further on some kernels

How to detect it

There are no network indicators. Hunt hosts for kernel failures and local driver-bind activity. Review dmesg, journalctl -k, kern.log, and crash dumps for oops/panic stacks naming serial-u16550, snd-serial-u16550, or ALSA serial UART probe. Audit privileged writes to driver bind/unbind interfaces and unexpected loading of snd-serial-u16550 on systems without serial MIDI hardware. Unpatched kernels may not log a dedicated warning, so a crash with this driver in the call trace is the main historical signal.

• snd-serial-u16550
• serial-u16550
• snd_serial_u16550
• ALSA: serial-u16550

What your security team should do

• Triage as low urgency: not KEV, EPSS 0.0022 with no 30-day rise, exploit maturity none, local-only
• Find Linux hosts that load snd-serial-u16550 and patch those kernels in the normal cycle
• If the driver is unused, blacklist it and lock down sysfs driver bind/unbind
• Track vendor kernel advisories for the ALSA serial-u16550 index check; no specific fixed versions were listed here
• Do not treat this as mass-exploitation or ransomware-related; no associated threat actors are reported