CVE-2026-98232 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Validate MODE SENSE lengths in scsi_cdl_enable()
scsi_cdl_enable() uses length fields returned by MODE SENSE to locate the ATA feature mode page in a 64-byte stack buffer. A target can report a total length shorter than its mode header and block descriptors. The unsigned subtraction used for the MODE SELECT length can wrap, and the separately computed buf_data can point beyond buf.
During automatic scan, enable is false, so the read-modify-write of buf_data[4] can clear the low two bits of a target-selected
out-of-bounds stack byte. scsi_mode_select() can then copy up to 64 bytes from outside the buffer into the outgoing MODE SELECT payload, disclosing stack contents to the target.
This is reachable while scanning a USB storage device that identifies as an ATA device and advertises CDL support. No filesystem mount or userspace access to the block device is required.
On upstream commit cee9395acd80 ("Linux 7.3-rc1"), a build-specific, one-vCPU QEMU/Raw Gadget proof using QEMU-only multi-UDC allocator sampling executed a fixed proof command inside the guest and created a UID-0-owned marker during automatic enumeration, with KASLR and NX enabled.
The issue was independently found during security research at Drivesec S.r.l.
Cap the available length to the buffer size. Validate and consume the mode header and block descriptor lengths before using the page, and require the five bytes needed to access the CDL field.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
This vulnerability represents a critical out-of-bounds read condition within the Linux kernel SCSI subsystem, specifically affecting the scsi_cdl_enable function which handles Command Descriptor List (CDL) support for ATA devices. The core technical flaw stems from insufficient validation of length fields returned by MODE SENSE commands during device enumeration. When a target reports mode data, the kernel uses these lengths to locate specific feature pages within a fixed 64-byte stack buffer allocated on the call stack. However, if a malicious or misconfigured storage target reports a total length that is shorter than the sum of its mode header and block descriptor sizes, an unsigned integer underflow occurs during the calculation of the remaining data length. This arithmetic error results in buf_data pointing to a memory address beyond the bounds of the allocated buffer, creating a classic out-of-bounds read scenario.
The operational impact of this flaw is significant because it allows for information disclosure without requiring any user interaction or filesystem mounting. The vulnerability is triggered during automatic device scanning, which occurs when a USB storage device identifies itself as an ATA device with CDL support. During the enable phase where the enable flag is false, the kernel performs a read-modify-write operation on buf_data[4]. This operation can inadvertently clear the low two bits of a stack byte located outside the intended buffer boundaries due to the pointer miscalculation. Subsequently, when scsi_mode_select() executes, it copies up to 64 bytes from this out-of-bounds location into the outgoing MODE SELECT payload sent back to the target device. This effectively leaks sensitive kernel stack contents, including potentially cryptographic keys or other privileged data, directly to an external storage controller connected via USB.
From a threat modeling perspective, this vulnerability aligns with CWE-125: Out-of-bounds Read and is exploitable in scenarios where physical access to the system's USB ports is available, classifying it under ATT&CK technique T1083: File and Directory Discovery or more specifically as an information exfiltration vector via peripheral devices. The severity is heightened by the fact that no authentication or elevated privileges are required for exploitation; any user with the ability to plug in a malicious USB device can trigger this code path during automatic enumeration. Proof of concept demonstrations have confirmed that on upstream kernels such as Linux 7.3-rc1, an attacker using QEMU with Raw Gadget emulation and multi-UDC allocator sampling could execute fixed proof commands within the guest environment. These exploits successfully created UID-zero owned markers even when Kernel Address Space Layout Randomization (KASLR) and No-eXecute (NX) protections were enabled, demonstrating that this flaw can bypass common mitigations to achieve arbitrary code execution or persistent privilege escalation depending on the specific kernel version and configuration.
To mitigate this vulnerability, developers must implement strict validation of all length fields returned by MODE SENSE commands before they are used for buffer indexing calculations. The scsi_cdl_enable function should cap the available length to the size of the allocated stack buffer to prevent any arithmetic underflow from resulting in a valid but out-of-bounds pointer. It is essential to validate and consume mode header and block descriptor lengths sequentially, ensuring that subsequent page access does not exceed buffer boundaries. Furthermore, the code must explicitly require at least five bytes for accessing the CDL field before proceeding with operations on buf_data. By enforcing these bounds checks during device enumeration rather than relying solely on higher-level protocol logic, the kernel can prevent both information disclosure and potential exploitation chains stemming from malformed SCSI responses.