CVE-2026-90324 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
ublk: check import_ubuf() return value
import_ubuf() can fail if the address range (provided by the userspace ublk server) is outside the allowed user address space. Return that 0 bytes were copied if import_ubuf() fails rather than passing an uninitialized struct iov_iter to ublk_copy_user_pages().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's block layer includes a character device interface known as ublk, which allows userspace applications to implement custom storage drivers by handling I/O requests directly. This architecture relies on the import_ubuf function to safely map user-space memory buffers into the kernel for data transfer operations. A critical flaw was identified in this process where the return value of import_ubuf was not adequately validated before proceeding with subsequent copy operations. Specifically, when a userspace ublk server provides an address range that falls outside the permitted user address space boundaries, the import_ubuf function fails to map these pages correctly. In such failure scenarios, the kernel previously continued execution without properly handling the error state, leading to the passing of an uninitialized struct iov_iter structure to the ublk_copy_user_pages routine.
This technical flaw represents a significant security risk because it allows for potential memory corruption or undefined behavior within the kernel space. By failing to check whether import_ubuf successfully mapped the user buffers, the system proceeds with operations on invalid data structures. The consequence of this oversight is that if the mapping fails due to an out-of-bounds address range, the ublk_copy_user_pages function receives garbage values in its iterator structure rather than a properly initialized state indicating zero bytes copied. This can lead to kernel panics, information leaks, or potentially arbitrary code execution depending on how the uninitialized memory is interpreted and used by downstream functions. The vulnerability stems from insufficient input validation regarding user-supplied addresses, which violates fundamental principles of safe buffer handling in operating system kernels.
From a classification perspective, this issue aligns with CWE-252, Unchecked Return Value, as the code failed to verify the success or failure status of a critical function call before using its results. Additionally, it relates to CWE-908, Use of Uninitialized Resource, because an uninitialized struct iov_iter was utilized in subsequent operations. In terms of attack vectors and tactics, this vulnerability could be leveraged by a local attacker with access to the ublk device node to trigger kernel instability or escalate privileges if they can craft specific memory mappings that exploit the lack of validation. This falls under ATT&CK technique T1059, Command and Scripting Interpreter, in contexts where such instabilities are chained for privilege escalation, though primarily it is a local exploitation vector involving improper input sanitization.
The operational impact of this vulnerability includes system instability through kernel crashes or panics when the flawed code path is triggered by maliciously crafted user-space requests. It also poses a risk to data integrity and confidentiality since uninitialized memory contents might be processed in ways that expose sensitive kernel information or corrupt storage operations. For organizations utilizing Linux-based systems with ublk enabled, this represents a tangible threat vector requiring immediate attention to maintain system reliability and security posture. The flaw highlights the importance of rigorous error handling in low-level subsystems where user-space interactions directly influence kernel memory management.
To mitigate this vulnerability, it is essential that all software relying on affected versions of the Linux kernel apply the provided patch or update to a version where import_ubuf return values are strictly checked. System administrators should ensure their kernels are updated to include fixes for this specific issue in the ublk subsystem. Furthermore, developers implementing custom storage drivers using ublk must adhere to strict validation practices, ensuring that all user-supplied address ranges are verified against allowed limits before being passed to kernel functions. Regular security audits and static analysis tools can help identify similar patterns of unchecked return values or uninitialized variable usage across other parts of the codebase to prevent analogous flaws from persisting in related components.