CVE-2026-89482
nicheWild kernel memory write in Linux nvme-tcp via malicious NVMe/TCP storage target
The Linux kernel's nvme-tcp initiator driver validated incoming C2HData (controller-to-host) transfers on blk_rq_payload_bytes() alone, while the command setup path also checks the request's physical segment count and records data_len. For WRITE_ZEROES commands — which have no physical segments but a non-zero request length — the receive iterator req->iter is never initialized and retains whatever the previous command on that tag left behind, so the driver-private area is only zeroed when the tag set is allocated. A malicious or compromised NVMe/TCP target can exploit this by sending a C2HData for a WRITE_ZEROES command, causing nvme_tcp_recv_data() to copy attacker-supplied data to a stale, arbitrary kernel address (reproduced as a KASAN wild-memory-access 512-byte write in a kworker). This yields kernel memory corruption on the initiator host — at minimum a kernel panic/DoS, and plausibly kernel code execution — but only against systems using the nvme-tcp initiator with a storage target the attacker controls or has compromised. The flaw is fixed upstream by adding req->data_len to the receive-side gate; no public PoC exists and no in-the-wild exploitation is known (not in CISA KEV).
What to do: Apply kernel updates containing this nvme-tcp fix as soon as stable backports are released for your distribution. Because exploitation requires the host to trust an attacker-influenced NVMe/TCP target, treat storage targets as privileged: connect initiators only to authenticated, dedicated storage networks with strict ACLs and segmentation, and audit for any target or fabric component that has been compromised or replaced. If patching is delayed, verify that hosts do not accept WRITE_ZEROES offload over nvme-tcp from untrusted targets and monitor initiators for unexpected crashes in nvme_tcp_io_work/nvme_tcp_recv_skb.
| Linux kernel (nvme-tcp driver) | Kernels prior to the fixing commit; exact stable version ranges not stated in the data (reproduced on a 7.2.0-rc5-based development tree; the bug follows the re |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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: 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.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.