CVE-2026-89973: nvme-tcp: check the data direction of a C2HData PDU
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: check the data direction of a C2HData PDU
nvmetcphandlec2hdata() 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 nvmetcprecvdata(), where copytoiter() hits WARNONONCE(i->datasource) 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 paniconwarn.
The send path already knows the direction - it consults rqdatadir() when it builds a command - and nvmetcphandler2t() 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/ioviter.c:193 at copytoiter+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: nvmetcpwq nvmetcpiowork [ 6.891875] RIP: 0010:copytoiter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] <TASK> [ 6.909254] skbdatagramiter+0x433/0x820 [ 6.911026] skbcopydatagramiter+0x37/0x120 [ 6.911622] nvmetcprecvskb+0xa07/0x4320 [ 6.913378] tcpreadsock+0x1ab/0x810 [ 6.915788] nvmetcptryrecv+0x152/0x1e0 [ 6.918222] nvmetcpiowork+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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel nvme-tcpto a version that resolves this vulnerability.Patch nvme-tcp: check the data direction of a C2HData PDU
Event History
Frequently Asked Questions
Who can trigger this issue?
An NVMe/TCP controller can trigger it by sending a C2HData PDU in response to a host write command. This means hosts connected to a malicious or faulty NVMe/TCP controller are exposed.
What is the practical impact on an affected host?
The malformed response causes a kernel warning, command failure, and controller reset. No data is copied and the issue is not memory corruption, but a host configured with panic_on_warn can panic.
Is there a mitigation if updating is not immediately possible?
Avoid connecting affected hosts to untrusted NVMe/TCP controllers. Where operationally acceptable, do not boot with panic_on_warn, since the warning is the condition that can make the issue fatal.