CVE-2026-90033: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix OOB write in sndusbmidius122loutput()
The sndusbmidius122loutput() picks a count of 2 on anything slower than high speed and never relates it to ep->maxtransfer. The URB buffer holds exactly maxtransfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from sndrawmiditransmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZEMAX.
Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usbmaxpacket(), which the USB core only clamps downward.
The akai and novation output ops in this file were given the same guard recently. Do the same here.
Affected Software
Event History
Frequently Asked Questions
Which connected devices can trigger the issue?
The vulnerable path can be triggered by a USB MIDI device that declares a one-byte bulk endpoint on a connection slower than USB high speed. The description specifically identifies the US-122MKII (USB ID 0644:8021) as falling through to the default packet-size handling.
What makes the memory corruption occur?
On non-high-speed connections, the output path uses a transmit count of two bytes without ensuring that it fits in the endpoint's max_transfer buffer. With a one-byte endpoint, the subsequent padding calculation underflows and can cause an out-of-bounds write.
Are all affected device IDs handled the same way?
No. Device IDs 0x800e and 0x800f are explicitly pinned to a nine-byte transfer size, while other devices use the default handling based on usb_maxpacket().