CVE-2026-4652: NVMe/TCP Target DoS Vulnerability

CVE-2026-4652 Overview

CVE-2026-4652 is a Denial of Service vulnerability affecting systems that expose an NVMe/TCP target. A remote, unauthenticated attacker can trigger a kernel panic by sending a specially crafted CONNECT command for an I/O queue containing a bogus or stale Controller ID (CNTLID). This results in a Null Pointer Dereference condition that crashes the target system.

The vulnerability stems from improper validation of the CNTLID field in incoming NVMe-oF (NVMe over Fabrics) CONNECT requests. When the NVMe/TCP subsystem receives a connection request with an invalid controller identifier, it fails to properly handle the error condition, leading to a null pointer dereference in kernel space.

Critical Impact

Remote unauthenticated attackers can cause immediate kernel panic and system crash on any exposed NVMe/TCP target, resulting in complete service disruption.

Affected Products

• FreeBSD systems with NVMe/TCP target functionality enabled
• Systems exposing NVMe-oF (NVMe over Fabrics) targets via TCP
• Storage infrastructure utilizing NVMe/TCP for remote storage access

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-4652 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-4652

Vulnerability Analysis

This vulnerability is classified as CWE-476 (NULL Pointer Dereference). The flaw exists in the NVMe/TCP target implementation's handling of CONNECT commands. When a remote client initiates an I/O queue connection, it must provide a valid Controller ID (CNTLID) that references an existing administrative connection. The vulnerable code path fails to verify the validity of this identifier before dereferencing the associated controller structure.

The attack is particularly dangerous because NVMe/TCP targets are designed to be network-accessible storage endpoints. The protocol operates over standard TCP connections, making exploitation straightforward for any attacker with network access to the target port (typically TCP port 4420).

Root Cause

The root cause is insufficient input validation in the NVMe/TCP target's CONNECT command handler. When processing an I/O queue connection request, the code retrieves the controller structure based on the client-supplied CNTLID without first verifying that the identifier corresponds to a valid, active administrative session. This allows an attacker to supply an arbitrary or stale CNTLID value, causing the kernel to dereference a null or invalid pointer when attempting to access controller state.

Attack Vector

The attack exploits the NVMe-oF TCP transport protocol's connection establishment mechanism. An attacker needs only network connectivity to the NVMe/TCP target service to execute this attack.

The exploitation flow involves:

1. Establishing a TCP connection to the NVMe/TCP target port
2. Sending an NVMe-oF CONNECT command specifying QTYPE as I/O queue (rather than Admin queue)
3. Including a fabricated or stale CNTLID value that does not correspond to any valid controller session
4. The kernel attempts to look up the controller by CNTLID, receives a null result, and dereferences the null pointer
5. This triggers an immediate kernel panic, crashing the target system

No authentication is required, and the attack can be repeated indefinitely to maintain denial of service conditions. For technical implementation details, refer to the FreeBSD Security Advisory.

Detection Methods for CVE-2026-4652

Indicators of Compromise

• Unexpected kernel panics on systems running NVMe/TCP targets with references to NVMe-oF or nvmft in crash dumps
• Unusual NVMe/TCP connection attempts with invalid or non-existent CNTLID values in protocol logs
• Repeated TCP connections to NVMe/TCP ports (typically 4420) followed by immediate disconnections
• System crash logs indicating null pointer dereference in NVMe/TCP kernel modules

Detection Strategies

• Monitor NVMe/TCP target logs for CONNECT commands with unrecognized or invalid CNTLID values
• Implement network intrusion detection rules to identify malformed NVMe-oF protocol traffic
• Deploy kernel crash monitoring to correlate panics with NVMe/TCP subsystem activity
• Use packet capture on NVMe/TCP ports to analyze connection patterns for anomalies

Monitoring Recommendations

• Enable detailed logging for NVMe/TCP target services to capture connection metadata
• Configure automated alerting for kernel panics on systems hosting NVMe/TCP targets
• Monitor network flows to NVMe/TCP ports for unexpected source addresses or connection patterns
• Implement baseline monitoring for normal NVMe/TCP traffic patterns to identify deviations

How to Mitigate CVE-2026-4652

Immediate Actions Required

• Apply the security patch from FreeBSD as described in FreeBSD-SA-26:07.nvmf
• Restrict network access to NVMe/TCP target ports using firewall rules to trusted clients only
• Consider temporarily disabling NVMe/TCP target functionality if not critical to operations
• Implement network segmentation to isolate NVMe/TCP storage infrastructure from untrusted networks

Patch Information

FreeBSD has released a security advisory addressing this vulnerability. System administrators should apply the patch referenced in FreeBSD-SA-26:07.nvmf. The fix adds proper validation of CNTLID values before attempting to dereference the associated controller structure, ensuring that invalid or stale identifiers are rejected with an appropriate error response rather than causing a kernel panic.

Workarounds

• Implement strict firewall rules to allow NVMe/TCP connections only from known, trusted storage initiators
• Deploy NVMe/TCP targets behind VPN or other network-layer authentication mechanisms
• Use network access control lists (ACLs) to restrict access to NVMe/TCP ports at the switch or router level
• Consider implementing IPsec or other transport-layer security for NVMe/TCP communications to provide authentication

# Example: Restrict NVMe/TCP access using pf firewall (FreeBSD)
# Add to /etc/pf.conf to allow only trusted initiators
pass in on $ext_if proto tcp from { 192.168.10.0/24 } to any port 4420
block in on $ext_if proto tcp to any port 4420