CVE-2026-22998 Overview
A NULL pointer dereference vulnerability has been identified in the Linux kernel's NVMe-TCP (NVMe over TCP) target subsystem, specifically in the nvmet_tcp_build_pdu_iovec function. This vulnerability allows remote attackers to trigger kernel panics by sending malformed H2C_DATA Protocol Data Units (PDUs) before proper command initialization has occurred.
The flaw originates from incomplete validation introduced in a previous security patch (commit efa56305908b) that addressed H2C PDU length validation but failed to verify whether critical data structures (cmd->req.sg and cmd->iov) were properly initialized before dereferencing them.
Critical Impact
Remote attackers can cause system denial of service by crashing the Linux kernel through crafted NVMe-TCP packets, affecting any system running the NVMe-TCP target subsystem.
Affected Products
- Linux kernel with NVMe-TCP target subsystem enabled
- Systems running nvmet-tcp kernel module
- NVMe-oF (NVMe over Fabrics) storage targets using TCP transport
Discovery Timeline
- 2026-01-25 - CVE CVE-2026-22998 published to NVD
- 2026-01-26 - Last updated in NVD database
Technical Details for CVE-2026-22998
Vulnerability Analysis
The vulnerability resides in the NVMe-TCP target implementation within the Linux kernel. When processing H2C_DATA (Host to Controller Data) PDUs, the nvmet_tcp_build_pdu_iovec() function directly dereferences the cmd->req.sg and cmd->iov pointers without verifying they have been properly initialized.
A previous fix attempted to add bounds checking for ttag and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but this was insufficient. The code path still allows H2C_DATA PDUs to be processed in scenarios where the associated command structures remain uninitialized.
Root Cause
The root cause is missing NULL pointer validation for critical data structures before they are dereferenced in the PDU I/O vector building routine. The kernel assumes that any H2C_DATA PDU received corresponds to a fully initialized command, but the protocol flow allows packets to arrive before proper command setup:
- Pre-CONNECT scenario: H2C_DATA PDU sent after ICREQ/ICRESP handshake but before CONNECT command - both cmd->req.sg and cmd->iov are NULL
- READ command scenario: H2C_DATA PDU for a READ command results in cmd->req.sg being allocated but cmd->iov remaining NULL
- Uninitialized slot scenario: H2C_DATA PDU targeting an uninitialized command slot leaves both pointers NULL
Attack Vector
The attack can be executed remotely by any entity capable of establishing a TCP connection to an NVMe-TCP target service. The attacker initiates the NVMe-TCP protocol handshake (ICREQ/ICRESP) and then immediately sends a crafted H2C_DATA PDU before completing proper command initialization through CONNECT or write commands.
This attack does not require authentication and can be performed immediately after the initial protocol handshake, as the NVMe-TCP target processes the malicious PDU before validating command state. The resulting NULL pointer dereference causes a kernel panic, leading to immediate system unavailability.
Detection Methods for CVE-2026-22998
Indicators of Compromise
- Kernel panic messages referencing nvmet_tcp_build_pdu_iovec in stack traces
- Unexpected NVMe-TCP target service crashes without apparent cause
- Network captures showing H2C_DATA PDUs immediately following ICREQ/ICRESP without intervening CONNECT commands
- System logs indicating NULL pointer dereferences in NVMe-TCP subsystem
Detection Strategies
- Monitor kernel logs for panic events involving nvmet_tcp module functions
- Implement network intrusion detection rules to identify anomalous NVMe-TCP protocol sequences
- Deploy endpoint detection monitoring for unexpected kernel crashes on storage target systems
- Analyze NVMe-TCP traffic patterns for protocol state violations
Monitoring Recommendations
- Enable kernel crash dump collection to capture diagnostic information for forensic analysis
- Configure alerting on systems running NVMe-TCP targets for unexpected service restarts
- Implement rate limiting and connection monitoring for NVMe-TCP listener ports (typically 4420/tcp)
- Review system stability metrics for NVMe-oF storage infrastructure
How to Mitigate CVE-2026-22998
Immediate Actions Required
- Apply the kernel patches from the official Linux kernel stable branches immediately
- Restrict network access to NVMe-TCP target ports using firewall rules to trusted hosts only
- Monitor NVMe-TCP target systems for unusual crash patterns or service disruptions
- Consider temporarily disabling NVMe-TCP target functionality if not critical to operations
Patch Information
The Linux kernel maintainers have released patches to address this vulnerability. The fix validates both cmd->req.sg and cmd->iov pointers before calling nvmet_tcp_build_pdu_iovec(), ensuring all required data structures are initialized before processing H2C_DATA PDUs.
Patches are available through the following kernel commits:
Workarounds
- Implement network-level access controls to restrict NVMe-TCP port access to authenticated management networks
- Deploy firewall rules limiting connections to port 4420/tcp from trusted initiator hosts only
- Unload the nvmet-tcp kernel module if NVMe-TCP target functionality is not required
- Consider using alternative NVMe-oF transport mechanisms (RDMA) where applicable
# Restrict NVMe-TCP access using iptables
iptables -A INPUT -p tcp --dport 4420 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 4420 -j DROP
# Disable NVMe-TCP target module if not needed
modprobe -r nvmet-tcp
echo "blacklist nvmet-tcp" >> /etc/modprobe.d/nvme-tcp.conf
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
