CVE-2026-90033 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()
The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX.
Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), 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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
This vulnerability represents a critical out-of-bounds write flaw within the Linux kernel's Advanced Linux Sound Architecture, specifically affecting the USB MIDI subsystem driver for certain devices such as the Tascam US-122 series. The root cause lies in the snd_usbmidi_us122l_output function, which handles data transmission to connected USB audio interfaces. When operating on non-high-speed connections or with specific endpoint configurations, this routine selects a transfer count of two bytes regardless of the actual buffer capacity defined by ep->max_transfer. This logic fails to validate whether the requested write size exceeds the allocated URB (USB Request Block) buffer limits, creating a scenario where memory corruption can occur during data padding operations.
The technical mechanism of exploitation involves integer underflow leading to excessive memory writes. When a device declares a bulk endpoint with a maximum packet size of only one byte, but the driver attempts to transmit two bytes via snd_rawmidi_transmit(), the subsequent memset operation calculates the remaining space by subtracting the transmitted count from the buffer size. Specifically, computing 1 minus 2 results in an integer underflow that wraps around to SIZE_MAX on signed integers or a very large positive number depending on implementation details. Consequently, the kernel attempts to fill this massive calculated length with padding data, writing far beyond the bounds of the allocated URB buffer and corrupting adjacent memory structures.
The operational impact of this vulnerability is severe, as it allows for potential remote code execution or system instability if an attacker can control the input data sent to the vulnerable USB device. By manipulating the MIDI stream sent through a compromised or maliciously configured interface, an adversary could trigger the out-of-bounds write, potentially overwriting critical kernel pointers, function return addresses, or other sensitive security structures. This aligns with CWE-787, which classifies out-of-bounds writes as a fundamental memory safety violation that undermines system integrity and confidentiality. The vulnerability is particularly dangerous because it occurs in a commonly used subsystem for audio production hardware, increasing the attack surface for users who connect external MIDI controllers or interfaces to their systems.
Mitigation strategies primarily involve applying the upstream kernel patch that introduces proper bounds checking similar to those recently implemented for Akai and Novation output operations. Developers must ensure that the transfer count is explicitly validated against ep->max_transfer before initiating any memory copy or padding operations. Additionally, system administrators should keep their Linux kernels updated to versions where this logic error has been corrected. From a defensive perspective, enabling kernel hardening features such as KASAN (Kernel Address Sanitizer) during development and testing phases can help detect such off-by-one errors early in the software lifecycle. This incident also highlights the importance of adhering to secure coding practices that mandate explicit validation of all buffer sizes against user-controlled or device-reported parameters before performing memory operations, a principle central to preventing CWE-787 type vulnerabilities across operating system kernels and embedded systems alike.