CVE-2026-89973 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: check the data direction of a C2HData PDU
nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller.
No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn.
The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all.
Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning.
[ 6.885580] ------------[ cut here ]------------
[ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71
[ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy)
[ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work
[ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330
[ 6.903739] Call Trace:
[ 6.904085] <TASK>
[ 6.909254] __skb_datagram_iter+0x433/0x820
[ 6.911026] skb_copy_datagram_iter+0x37/0x120
[ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320
[ 6.913378] __tcp_read_sock+0x1ab/0x810
[ 6.915788] nvme_tcp_try_recv+0x152/0x1e0
[ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0
[ 6.926906] </TASK>
[ 6.927226] ---[ end trace 0000000000000000 ]---
[ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data
[ 6.928709] nvme nvme0: receive failed: -14
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel's NVMe over TCP implementation contains a logic flaw in the handling of Command-to-Host Data Protocol Data Units that can lead to service disruption through controller resets and potential system panics. The vulnerability resides within the nvme_tcp_handle_c2h_data function, which is responsible for processing data received from an NVMe controller destined for the host. While this routine correctly identifies the specific request associated with a command identifier and verifies the presence of a payload, it fails to validate the directionality of that original I/O operation. Specifically, the code does not confirm whether the underlying SCSI or block layer request was intended as a read operation requiring data transfer from the device to memory. This oversight allows a malicious or misbehaving NVMe controller to exploit this gap by responding to a write command with Command-to-Host Data PDUs, which are strictly meant for read operations where data flows from storage to host.
When such an invalid PDU is processed, the kernel attempts to copy the incoming network data into the user-space buffer or kernel memory structure associated with the request using _copy_to_iter. Because this function expects a write direction (data going out) but receives input intended for a read context, it triggers a critical internal assertion failure via WARN_ON_ONCE on the i->data_source field. This assertion does not result in traditional memory corruption or arbitrary code execution since no actual data is written to unintended locations; rather, it generates a kernel warning trace that includes detailed stack information and CPU state. In standard configurations, this results in an error return value of zero from the copy function, which propagates up through the network receive path as -EFAULT, ultimately causing the NVMe driver to mark the queue failure and reset the controller connection to restore stability.
The operational impact of this vulnerability is primarily centered on availability rather than confidentiality or integrity. An attacker with access to an unpatched host's NVMe-over-TCP interface can trigger repeated controller resets by sending crafted C2HData PDUs in response to write commands. This denial-of-service condition becomes significantly more severe if the target system has been booted with the panic_on_warn kernel parameter enabled, which is common in production environments seeking strict adherence to warning protocols. In such configurations, the WARN_ON_ONCE trigger causes an immediate kernel panic and full system reboot rather than a simple driver reset, leading to complete service interruption. The send path of the NVMe TCP implementation already correctly consults rq_data_dir when constructing commands, highlighting that this directional check was simply omitted from the receive-side validation logic despite its critical importance for protocol correctness.
This flaw aligns with CWE-20 Improper Input Validation, as the application fails to adequately verify input parameters before processing them, specifically neglecting to validate the semantic direction of the data transfer against the original command intent. From a threat modeling perspective using MITRE ATT&CK techniques, this vulnerability facilitates Denial of Service via resource exhaustion or logic errors (T1499) and potentially impacts Availability by disrupting critical storage services. The remediation strategy involves modifying nvme_tcp_handle_c2h_data to explicitly check the data direction of the associated request before attempting any data copy operations. By rejecting C2HData PDUs that do not correspond to read commands, the driver ensures protocol compliance at an earlier stage in the processing pipeline. This prevents the invocation of _copy_to_iter with mismatched directions, thereby eliminating the kernel warning and preventing the subsequent controller reset or system panic, ensuring robust operation even when interacting with non-compliant or adversarial NVMe controllers.