EUVD-2026-80573
GHSA-9393-xpw8-3983
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
Rogue controller triggers at will over the network (AV:N/AC:L/PR:N/UI:N); no data copied so C:N/I:N; A:H reflects panic_on_warn kernel panic (A:L for the default controller-reset case).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
7DescriptionCVE.org
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
AnalysisAI
Denial of service in the Linux kernel's NVMe-over-TCP (nvme-tcp) host driver, where nvme_tcp_handle_c2h_data() accepts a controller-to-host data PDU for a command that did not request a read; the receive path then hits WARN_ON_ONCE(i->data_source) inside _copy_to_iter(), returns -EFAULT, and resets the controller. The impacted component is the initiator side of the NVMe-oF TCP transport, so hosts are only at risk when they attach to a malicious or compromised NVMe-oF TCP target that can dictate PDU sequencing; there is no public exploit identified at time of analysis, and the practical severity is modest because the trigger requires control of the storage controller the host talks to (inverted trust model). …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires a Linux host using the nvme-tcp (NVMe-over-TCP) transport that connects/attaches to a malicious or compromised NVMe-oF TCP controller; the host issues a write command and the controller responds with a C2HData PDU naming that command, which the host fails to reject due to the missing data-direction check. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | This is a genuine but modest-severity denial-of-service issue in the Linux kernel NVMe-over-TCP HOST (initiator) driver, not the target. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Vendor-released patch: update to Linux 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5, or 7.3-rc2 (or apply the matching stable backport commit, e.g. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all Linux hosts using the NVMe-over-TCP initiator (nvme-tcp) and identify any booted with panic_on_warn, then apply the vendor-released patch for CVE-2026-89973 (confirm the exact fixed kernel version in your distribution vendor's advisory) or, if immediate patching is not possible, isolate those hosts from untrusted NVMe-oF TCP targets and consider disabling the nvme-tcp module where it is not required; within 7 days, apply the vendor patch to all remaining affected hosts, verify the running kernel build against the vendor advisory, and restrict NVMe-oF TCP target access to trusted storage arrays; within 30 days, validate patch compliance across the fleet, review whether panic_on_warn is still operationally required, and add monitoring for nvme controller resets and kernel panics to detect any recurrence.
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today