CVE-2026-80973: ALSA: 6fire: bound the MIDI event length from the device
In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: bound the MIDI event length from the device
usb6firecommreceiverhandler() 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->receiverbuffer[0] == 0x10) / midi in event / if (midirt) midirt->inreceived(midirt, rt->receiverbuffer + 2, rt->receiverbuffer[1]); }
receiverbuffer is a 64-byte kzalloc() buffer (COMMRECEIVERBUFSIZE), so only 62 bytes follow the two-byte header. receiverbuffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes sndrawmidireceive() 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->actuallength 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 usb6firecomminit() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6firemidiinreceived() only calls sndrawmidireceive() 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 sndrawmidireceive Read of size 255 at addr ffff000009f64682 by task bash/183 asanmemcpy sndrawmidireceive usb6firemidiinreceived [sndusb6fire] usb6firecommreceiverhandler [sndusb6fire] Allocated by task 11: usb6firecomminit [sndusb6fire] usb6firechipprobe [sndusb6fire] 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 transferbufferlength, 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>
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (snd_usb_6fire / ALSA)to a version that resolves this vulnerability.Fixed in 7.2.0-rc5 - Configuration
In usb6fire_comm_receiver_handler()/snd_rawmidi_receive path, reject the MIDI event when the device-supplied length byte would exceed the bytes that follow the 2-byte header within the receiver_buffer (64-byte COMM_RECEIVER_BUFSIZE / 62 bytes after header).
usb6fire (snd_usb_6fire) / MIDI receiver path bounds check on MIDI event length vs receiver_buffer = Drop/reject events when advertised length exceeds bytes following the 2-byte header - Configuration
Do not forward MIDI events based solely on the device header; ensure the URB status is good and validate that urb->actual_length covers the 2-byte header plus the advertised MIDI event length before reading/forwarding.
usb6fire (snd_usb_6fire) / URB handling urb->actual_length validation = Require transfer to have delivered header plus advertised event length
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using the Linux kernel’s 6fire USB audio driver are exposed when a connected device supplies a crafted MIDI-in event. A device can advertise a MIDI event length of up to 255 bytes even though only 62 bytes are available after the message header in the receiver buffer.
Does exploitation require a user to perform an action after the device is connected?
The receiver URB is submitted during device probe, so the out-of-bounds read can occur when the device is plugged in without further user action. For data beyond the buffer to be forwarded through the rawmidi read path, a MIDI input substream must be open.
Can a short USB transfer also trigger the issue?
Yes. The handler does not check urb->actual_length, so a short transfer can leave the type and length bytes from a prior transfer in the buffer and cause stale data to be processed.