CVE-2026-90227 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed()
Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a partition device or write through a read-only file descriptor.
Pass flags and open_for_write through and reject disallowed commands with -EACCES.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's NVMe driver contained a critical access control flaw within the implementation of the SUBMIT_IO ioctl interface, which allowed unprivileged users to bypass standard security restrictions on block device operations. This vulnerability stems from an inconsistency in how different command submission mechanisms validate user permissions and intent. Specifically, while other IOCTL commands such as IO_CMD and IO64_CMD correctly invoke the nvme_cmd_allowed function to verify that a requested operation is permitted for the current context, the SUBMIT_IO path failed to perform this essential check. This oversight created a significant gap in the kernel's security model, effectively allowing local users with low-level privileges to execute arbitrary I/O commands on NVMe devices without proper authorization checks.
The technical root cause lies in the lack of parameter validation and permission verification during the handling of SUBMIT_IO requests. In a secure system design, any attempt to submit direct input/output operations must ensure that the caller has appropriate write permissions for the target device and that the specific command being issued is allowed by security policies. By omitting the call to nvme_cmd_allowed, the kernel failed to distinguish between read-only and writable contexts or verify if the user had permission to access a specific partition on an NVMe drive. This omission meant that even when a file descriptor was opened with read-only permissions, or when targeting partitions where write access should be restricted, the driver would still process the submission of I/O commands without raising an error.
The operational impact of this vulnerability is severe, as it enables unauthorized data modification and potential system compromise through direct hardware interaction. An unprivileged attacker could exploit this flaw to write malicious code directly to disk sectors that are typically protected by file system permissions or partition boundaries. This capability undermines the integrity guarantees provided by the operating system's storage layer, allowing for persistent malware installation, corruption of critical system files, or exfiltration of sensitive data stored on NVMe drives. Furthermore, because this affects block device I/O at a low level, it bypasses higher-level security controls such as SELinux or AppArmor policies that rely on standard file descriptor checks rather than direct hardware command validation.
This issue is classified under CWE-269, which covers Improper Privilege Management, specifically reflecting the failure to enforce proper access control for system resources. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability facilitates Local Privilege Escalation and potentially Data Manipulation by allowing an attacker to write directly to storage media without administrative rights. The exploitation vector is local, requiring physical or remote shell access to the affected Linux host, but once achieved, it provides a powerful mechanism for bypassing standard security boundaries inherent in Unix-like permission models.
To mitigate this vulnerability, system administrators and developers must ensure that the kernel patch implementing the fix is applied promptly. The resolution involves modifying the SUBMIT_IO ioctl handler to pass necessary flags and open file mode information through to the nvme_cmd_allowed function. This ensures that any command submission is explicitly checked against allowed operations based on the current user's privileges and the nature of the opened device descriptor. If a command is deemed disallowed by this check, the system must reject it with an EACCES error code, thereby restoring the intended security posture where only authorized users can perform write operations or access restricted partitions via direct NVMe commands.