CVE-2026-80973

What it actually does

The Linux ALSA USB 6fire receiver completion path treats a device-chosen MIDI length byte as trusted and passes it to snd_rawmidi_receive() without clamping it to the 64-byte COMM receiver buffer or to urb->actual_length. Only 62 bytes follow the two-byte header, so an oversized length (up to 255) causes a kernel heap out-of-bounds read; adjacent slab bytes are then copied into the userspace raw MIDI input path. Short URB completions can also act on stale type/length bytes left in the buffer. The receiver URB is submitted at probe, so the read can occur on device attach whenever a MIDI input substream is open. This is a local USB-triggered information disclosure (OOB read), not a remote network flaw and not a confirmed kernel write primitive.

Why it matters to the business

Impact is limited to Linux systems that load the niche snd-usb-6fire driver and that allow untrusted USB devices to be attached (physical ports, kiosks, labs, or USB redirection into VMs). Leaked kernel heap contents can expose pointers or other secrets that assist a follow-on local privilege-escalation attempt. Organizational urgency is low-to-moderate: exploit maturity is none, the issue is not in CISA KEV, it is not associated with ransomware, EPSS is about 0.22% and flat over 30 days, and the CVE is only ~20 days old. Treat it as standard kernel patch hygiene unless you routinely accept unknown USB audio/MIDI gadgets.

How an attack unfolds

An attacker who can present USB devices to a vulnerable Linux host enumerates a gadget that the 6fire driver binds to. Probe submits the 64-byte communication receiver URB. The gadget returns a MIDI-in event whose length field exceeds the bytes actually following the header (and may complete a short transfer so the handler uses leftover header bytes). If any process has the MIDI input substream open, the driver forwards the untrusted length into snd_rawmidi_receive(), which copies kernel memory past the allocation into the raw MIDI read stream. The attacker then consumes that stream from userspace. No named threat actors or campaigns are reported, and there is no public exploit maturity.

How to fix it

Install distribution or vendor kernel updates that include the ALSA 6fire change to reject MIDI events whose length exceeds the bytes after the header and to require urb->actual_length to cover the header plus that length. This record does not list exact fixed package versions, so confirm via vendor changelog or by inspecting usb6fire_comm_receiver_handler() for those bounds. Until patched, unload and blacklist snd-usb-6fire on hosts that do not use TerraTec DMX 6Fire USB hardware, and apply USB allowlisting so unknown gadgets cannot bind the driver.

How to confirm the fix worked

Verify the running kernel changelog or package advisory mentions bounding the 6fire MIDI event length and checking URB actual length. On hosts, confirm snd-usb-6fire is absent from lsmod and from autoload/blacklist policy if the hardware is unused. After upgrade, the receiver handler must drop events longer than the 62-byte payload window or shorter than header-plus-length. Do not validate by sending malformed USB MIDI frames on production systems.

Typical attack path

1. Obtain the ability to attach USB devices to a Linux host that can load snd-usb-6fire (physical access, malicious peripheral, or USB passthrough).
2. Enumerate a USB function that the 6fire driver probes so the communication receiver URB is submitted.
3. Have a MIDI input substream open, or wait for a legitimate application to open it.
4. Complete the receiver URB as a MIDI-in event with an unbounded length (or a short transfer that leaves stale header bytes).
5. Read the oversized MIDI payload from the raw MIDI device to obtain adjacent kernel heap contents.
6. Use any leaked kernel data as a local information-disclosure primitive; no in-the-wild ransomware or APT use is documented.

How to detect it

This is an out-of-bounds kernel read and is often silent on production kernels without KASAN or similar sanitizers, so lack of crashes does not prove it was unused. Search historical dmesg, journald kernel logs, kdump/vmcore, and sanitizer reports for slab-out-of-bounds or oops in snd_rawmidi_receive attributed to usb6fire_midi_in_received or usb6fire_comm_receiver_handler, and correlate with USB device-add and snd-usb-6fire probe timestamps. Review which processes had ALSA raw MIDI input open around those events and whether an unexpected 6fire-like USB audio device appeared. There are no network traffic signatures. Named threat-actor hunting is not applicable.

• KASAN: slab-out-of-bounds in snd_rawmidi_receive
• usb6fire_comm_receiver_handler
• usb6fire_midi_in_received
• usb6fire_chip_probe
• usb6fire_comm_init
• snd_usb_6fire
• snd-usb-6fire

What your security team should do

• Inventory Linux images for snd-usb-6fire (loaded, packaged, or USB-alias autoload) and prioritize those kernels for the vendor ALSA 6fire patch.
• Blacklist snd-usb-6fire wherever TerraTec DMX 6Fire USB hardware is not required.
• Enforce USB device authorization so untrusted audio/MIDI gadgets cannot bind at probe.
• Watch kernel logs and crash dumps for 6fire probe plus snd_rawmidi_receive sanitizer or oops hits; this is not a KEV-driven emergency given no known exploitation and low, flat EPSS.