Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:29.730Z",
  "pubdate": "2026-09-11T20:19:29.730Z",
  "executiveSummary": "A memory corruption vulnerability exists in the Linux kernel's nvme-tcp driver, specifically related to the handling of C2HData (Controller-to-Host Data) frames.\nThe vulnerability is a wild-memory-access issue triggered when the driver incorrectly processes C2HData for commands that lack associated physical segments, such as REQ_OP_WRITE_ZEROES.\nBy sending a malicious C2HData frame for a tag previously used for a WRITE_ZEROES command, an attacker can induce the kernel to copy data into an invalid or stale memory location.\nThis flaw allows for potential kernel-level memory corruption, which may lead to system crashes (DoS) or potentially arbitrary code execution depending on the state of the memory at the target address.\nExploitation requires a compromised or malicious NVMe-over-TCP target capable of sending unsolicited or mismatched C2HData frames to the host.\nThe issue stems from an insufficient validation of request state, where the driver fails to ensure that the receive buffer is valid before processing incoming data.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper synchronization between the command setup phase and the data receive phase within the nvme-tcp transport driver. Specifically, the driver logic uses blk_rq_payload_bytes() to determine if a data transfer is expected for a given command. However, for certain operations like REQ_OP_WRITE_ZEROES, blk_rq_bytes() may return a non-zero value despite the operation having no physical segments.\nIn the vulnerable implementation, the driver's receive logic incorrectly assumes that a non-zero payload byte count implies a valid destination for C2HData frames. Because the setup phase detects no physical segments, it leaves the request's iterator (req->iter) untouched. When the target sends a C2HData frame for a command tag that was recently used for a WRITE_ZEROES operation, the nvme_tcp_recv_data() function attempts to copy the incoming data into a stale iterator context leftover from a previous operation on that same tag.\nThe attack flow proceeds as follows: First, an attacker (acting as an NVMe-TCP target) establishes a connection with the host. Second, the attacker induces the host to execute a WRITE_ZEROES command, which the driver prepares but does not initialize with a data iterator. Third, the attacker sends a C2HData frame assigned to the same command tag. The kernel, misinterpreting this as a valid data-in transmission, invokes _copy_to_iter() with the stale/uninitialized iterator. This results in a wild memory access (KASAN report: 'wild-memory-access in _copy_to_iter'), as the kernel attempts to write the frame's payload to an arbitrary address previously mapped in the stale iterator.\nThe impact of this vulnerability is significant, as it leads to an out-of-bounds or wild memory write, resulting in an immediate kernel panic (BUG: KASAN: wild-memory-access). If successfully leveraged, this could be used to overwrite critical kernel data structures, potentially leading to privilege escalation or reliable code execution from the context of the network worker thread (nvme_tcp_io_work). The vulnerability is persistent across requests if the target maintains tag persistence and exploits the lack of buffer verification in the recv path."
}