CRITICAL
nvme-tcp C2HData OOB
CVE-2026-89482
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
KernelScan AI9.8CRITICAL
01Description
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: <TASK> dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.
02KernelScan AI Analysis
Risk summary
A malicious or compromised NVMe-TCP target can exploit a missing validation check in the initiator's receive path to trigger a wild memory write on the connecting host. The write targets a stale iterator from a previous command, corrupting arbitrary kernel memory. Any system that connects to an NVMe-TCP target is at risk; the attacker needs only network reachability and no privileges on the victim.
Vulnerability analysis
The NVMe-TCP initiator driver allowed incoming data from the storage target whenever a block request reported a non-zero payload size, without confirming that the request actually had a valid data buffer. For certain commands that report a byte count but carry no physical data segments, the setup path correctly skips buffer initialization, yet the receive path still accepted the data and copied it into a stale buffer reference left from an earlier command on the same tag. This causes a wild memory write to an attacker-influenced address. The fix adds the same buffer-validity checks to the receive path that the setup path already uses, so incoming data is rejected when no valid buffer is present. Any host connected to a malicious NVMe-TCP target is exposed; the attacker needs no privileges on the victim system, only an established TCP connection to send malicious traffic.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.10 | — | 5.10.270 | 7ed0b61bbc14 |
| 5.15 | — | 5.15.221 | b96e1ff75e5c |
| 5.4 | 5.4.36 | 5.5 | 32ea8ce96b9b |
| 5.6 | 5.6.8 | 5.7 | dd8906bb8f8d |
| 6.1 | — | 6.1.188 | b36161701cb3 |
| 6.12 | — | 6.12.109 | 641ad3a30ba5 |
| 6.18 | — | 6.18.50 | 3a4aa9e6ad3e |
| 6.6 | — | 6.6.157 | 6a01b5826310 |
| 7.2 | — | 7.2.4 | — |
| mainline | — | 7.3 | — |
| cip/5.10 | — | 5.10.271-cip78 | 32ea8ce96b9b |
| cip/6.1 | — | 6.1.189-cip61 | 7ed0b61bbc14 |
| cip/6.1-rt | — | 6.1.189-cip61-rt32 | 7ed0b61bbc14 |
| cip/6.12 | — | 6.12.111-cip32 | b36161701cb3 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.111-cip32 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Fixed in 5.10.271-cip78 |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |