CVE-2026-80972

What it actually does

The Linux kernel ALSA loopback driver (snd-aloop) trusted an unchecked card index from the device pointer at probe time. When a device is bound manually through sysfs, that index can be -1 ("none"), causing out-of-bounds reads and writes against the driver's index[] and related parameter arrays in kernel memory. The result is kernel memory corruption, a kernel oops or panic, and a theoretical path to further privilege impact if the corrupted structures are subsequently used.

Why it matters to the business

This is a local kernel integrity and availability issue, not a remote network worm. An unprivileged or low-privilege local user who can bind snd-aloop via sysfs may crash the host or, in a worst case, attempt to escalate privileges. There is no CISA KEV listing, no reported ransomware use, exploit maturity is none, and EPSS remains very low (~0.00215) with a flat 30-day trend. Downstream product lists and exact fixed versions were not supplied, so risk is limited to Linux systems that load ALSA loopback. Patching should follow normal kernel update cadence unless hosts already expose untrusted local or container bind access to this driver.

How an attack unfolds

An attacker who already has local code execution on a Linux host (or a container/VM with sufficient sysfs and module access) binds the ALSA loopback driver through the sysfs device interface using an invalid card index. Probe then indexes kernel arrays out of range. That typically produces an oops or panic; a skilled attacker might try to turn the same out-of-bounds access into controlled kernel memory corruption. No public exploit, named threat actor, or in-the-wild campaign is associated with this issue. Exploitation requires local access and a loaded or bindable snd-aloop driver, not unauthenticated remote reachability.

How to fix it

Apply a Linux kernel update that includes the ALSA aloop probe-time card-index validity check (warn and correct out-of-range values). Because no per-distro or per-package fixed versions were provided, obtain the patched kernel from your vendor or stable tree and confirm the aloop probe path rejects invalid indexes. Until patched, restrict who can bind devices via sysfs, avoid manually binding snd-aloop with an unspecified card id, and do not expose this driver to untrusted local users or containers. Reboot into the patched kernel so the running image is updated.

How to confirm the fix worked

Confirm the running kernel changelog or aloop source contains a card-index range check at probe. After reboot, verify snd-aloop still initializes devices the driver creates itself, and that a sysfs bind with an out-of-range or "none" id is rejected or corrected with a kernel warning instead of an oops. Inventory hosts that load snd-aloop (lsmod, module autoload configs, audio loopback use) to find remaining unpatched exposure. Do not use a crash-inducing bind as a production validation test.

Typical attack path

1. Gain local access to a Linux system where snd-aloop can be loaded or bound
2. Use the sysfs bind/probe path rather than the driver's normal module-created devices
3. Supply an invalid card index (for example the "none" / -1 case) so probe indexes past index[] and related arrays
4. Trigger kernel out-of-bounds access during aloop probe
5. Cause a denial of service via oops/panic, or attempt to abuse the corrupted kernel state for further local privilege impact

How to detect it

There is no known in-the-wild campaign, so hunt for local misuse rather than a signatured payload. Review kernel logs (journald/dmesg/kern.log) around probe of snd-aloop for oops, panic, or out-of-bounds access in aloop probe; look for sysfs bind/unbind of the aloop device shortly before a crash. After the fix, treat new warnings about an invalid card index as evidence of a bad bind attempt. Correlate with local audit of writes under sysfs device bind paths and module loads of snd-aloop. Absence of these artifacts does not prove non-exploitation of a brief crash that left no persisted logs.

• snd-aloop
• aloop_probe
• Oops:.*aloop
• BUG: unable to handle kernel paging request
• invalid card index
• sysfs.*bind
• kernel: ALSA.*aloop

What your security team should do

• Prioritize kernel updates on hosts that load snd-aloop or allow untrusted users to bind ALSA devices via sysfs
• Treat this as a local kernel hardening fix, not an emergency remote KEV-style outage, given low EPSS, no KEV, and no known exploits
• Lock down sysfs device bind/unbind and kernel module load for non-admin users and untrusted containers
• Monitor kernel logs for aloop-related oopses and out-of-range card index warnings after patching
• Track vendor kernel advisories for the exact package version that carries this aloop sanity check