# CVE-2026-80973: ALSA: 6fire: bound the MIDI event length from the device

> A malicious USB device can trigger an out-of-bounds read in the ALSA 6fire driver, leaking kernel memory to userspace via the MIDI input path.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 11 Sep 2026
- **Updated:** 19 Oct 2026
- **Also known as:** AZL-100458, BELL-CVE-2026-80973, DEBIAN-CVE-2026-80973, GHSA-xqvm-46mc-2mf2, UBUNTU-CVE-2026-80973

## What is CVE-2026-80973?

CVE-2026-80973 is a vulnerability in Linux, published on 11 Sep 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

ALSA: 6fire: bound the MIDI event length from the device

usb6fire_comm_receiver_handler() forwards a MIDI event using a length
byte the device supplies, with no bound and no check that the transfer
delivered that many bytes:

	if (!urb->status) {
		if (rt->receiver_buffer[0] == 0x10) /* midi in event */
			if (midi_rt)
				midi_rt->in_received(midi_rt,
						rt->receiver_buffer + 2,
						rt->receiver_buffer[1]);
	}

receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so
only 62 bytes follow the two-byte header.  receiver_buffer[1] is a u8 the
device chooses, so a device that answers with 0x10 and a length of 0xFF
makes snd_rawmidi_receive() read 255 bytes starting two bytes into a
64-byte object.  The bytes past the buffer are handed to userspace
through the rawmidi read path.

urb->actual_length is not consulted either, so a short transfer leaves
both the type byte and the length byte at their previous values and the
handler acts on stale data.

The receiver URB is submitted from usb6fire_comm_init() at probe, so the
read happens on plug with no user action; forwarding to userspace also
needs a MIDI input substream open, since usb6fire_midi_in_received()
only calls snd_rawmidi_receive() when rt->in is set.

KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device:

  BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive
  Read of size 255 at addr ffff000009f64682 by task bash/183
   __asan_memcpy
   snd_rawmidi_receive
   usb6fire_midi_in_received [snd_usb_6fire]
   usb6fire_comm_receiver_handler [snd_usb_6fire]
  Allocated by task 11:
   usb6fire_comm_init [snd_usb_6fire]
   usb6fire_chip_probe [snd_usb_6fire]
  The buggy address is located 2 bytes inside of
   allocated 64-byte region [ffff000009f64680, ffff000009f646c0)

Reject the event when the length exceeds the bytes that follow the
header, and require the transfer to have delivered the header plus that
many bytes.  The receiver URB is submitted with a 64-byte
transfer_buffer_length, so a genuine device cannot deliver an event
longer than those 62 bytes and nothing valid is dropped.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

## Which versions are affected by CVE-2026-80973?


## How do I fix CVE-2026-80973?

Apply the vendor's patch.

## Is CVE-2026-80973 being exploited?

There is no known exploitation of CVE-2026-80973 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-80973 and fix it if it is affected.

What it is: CVE-2026-80973 is a vulnerability in Linux, published on 11 Sep 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of CVE-2026-80973 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-80973/ (Markdown: https://insights.sbomify.com/CVE-2026-80973/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-80973
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-80973
- OSV: https://osv.dev/vulnerability/CVE-2026-80973

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-80973/
Summaries are generated and may contain mistakes; the official description above is the record.