CVE-2026-80813 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix NULL pointer dereference in nvmet_execute_identify_nslist()
When a host issues an Identify command with CNS 07h (Active Namespace ID List for a specific I/O Command Set), nvmet_execute_identify_nslist() is called with match_css set. The command-set filter dereferences req->ns, but this handler never calls nvmet_req_find_ns(), so req->ns is always NULL (nvmet_req_init() resets it to NULL). As soon as an enabled namespace with an NSID greater than the requested value exists, req->ns->csi dereferences a NULL pointer and oopses.
Besides the crash, the comparison is logically wrong: to filter the list by command set it must test the command set of the namespace being iterated, not a single fixed value. Use the loop variable ns->csi.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel vulnerability identified in the nvmet subsystem represents a critical NULL pointer dereference within the NVMe target implementation, specifically affecting the identification of active namespaces for specific I/O command sets. This flaw occurs when an initiator issues an Identify command with Command Set Specific (CNS) value 07h, which requests the Active Namespace ID List filtered by a particular command set identifier. The kernel function nvmet_execute_identify_nslist() is invoked to handle this request and operates under the assumption that it can filter results based on the command set associated with the target namespace object referenced in the request structure. However, due to an initialization oversight, the pointer req->ns remains NULL because the handler fails to invoke nvmet_req_find_ns(), a function responsible for resolving the specific namespace context required for such operations. Consequently, when the code attempts to access the CSI field of this nullified namespace pointer during the filtering process, it triggers a kernel oops or panic, leading to an immediate denial of service condition for any system relying on NVMe target functionality.
From a technical perspective, the root cause lies in two distinct but related logical errors within the nvmet_execute_identify_nslist() function. First is the absence of proper namespace resolution prior to dereferencing pointer members, which violates basic memory safety principles and leads directly to the NULL pointer dereference described above. Second is a fundamental logic error in how the command set filtering is performed; instead of iterating through available namespaces and comparing each individual namespace's CSI against the requested filter value using the loop variable ns->csi, the code incorrectly attempts to use req->ns as the reference point for comparison. This not only causes the crash when no valid namespace context exists but also ensures that even if a valid pointer were present, the filtering logic would be semantically incorrect and fail to return accurate results according to NVMe specification requirements.
The operational impact of this vulnerability is significant for environments deploying Linux-based NVMe targets. An attacker or misconfigured client can trigger this condition simply by sending a standard Identify command with CNS 07h, provided that there exists at least one enabled namespace with an NSID greater than the requested value in the target configuration. This results in a kernel panic, effectively crashing the host system and causing widespread service disruption for all connected initiators dependent on storage services hosted via NVMe over Fabrics or local NVMe targets. The stability of enterprise storage infrastructure is compromised as this flaw allows remote code execution conditions to manifest as simple denial-of-service events through standard protocol commands that are part of normal operational workflows rather than malicious exploitation attempts, although the line between accidental trigger and intentional abuse remains thin in networked environments.
In terms of industry standards classification, this vulnerability aligns with CWE-476, which denotes a NULL Pointer Dereference, as it involves accessing memory through an uninitialized or null pointer leading to undefined behavior and system crash. Furthermore, given that the issue can be triggered by sending specific crafted commands over network interfaces in NVMe over Fabrics scenarios, it also relates to CWE-20 Improper Input Validation, specifically regarding the failure to validate object references before use. From a defensive security perspective, this aligns with MITRE ATT&CK technique T1498 Network Denial of Service, where an adversary disrupts availability by exploiting software flaws to cause system instability or crashes without needing elevated privileges initially, relying instead on protocol-level interactions that are often permitted in default configurations.
Mitigation strategies primarily involve applying the upstream kernel patches provided by Linux distribution maintainers which correct both the initialization sequence and the filtering logic within nvmet_execute_identify_nslist(). Administrators should ensure their systems are updated to versions containing these fixes immediately, particularly those running NVMe target services exposed to untrusted networks or multi-tenant environments. Until patching is complete, restricting access to NVMe target ports via firewall rules can reduce exposure, although this does not eliminate risk if legitimate initiators require such connectivity. Long-term remediation includes enforcing strict input validation and ensuring that all kernel subsystems properly initialize object references before dereferencing them, adhering to secure coding practices that prevent null pointer vulnerabilities from manifesting in production environments.