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
? __pfxtcpread_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.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - The nvme-tcp host receive path parses C2HData PDUs from a remote NVMe/TCP target over a routable TCP connection (typically port 4420); a malicious or compromised target, or an on-path attacker injecting into the stream, triggers the bug from the network.
AC:L - A malicious target can advertise WRITE_ZEROES, wait for tag reuse after a data command, and send C2HData for that in-flight WRITE_ZEROES; leftover iterator state is deterministic because driver-private fields are not cleared on reuse, so no race or memory-layout luck is required.
PR:N - NVMe/TCP authentication (TLS, DH-HMAC-CHAP) is optional and off by default; the vulnerable copy runs on C2HData from the connected peer, which needs no credentials or privileges on the victim host.
UI:N - Once the host is connected to the target as persistent storage, ordinary filesystem and block I/O generate WRITE_ZEROES commands; the attacker sends the crafted PDU without any further victim action.
S:U - The stale-iterator write corrupts memory in the same host kernel security authority; this is not a VM, IOMMU, or sandbox boundary crossing.
C:H - nvme_tcp_recv_data() writes attacker-controlled C2HData through a leftover iov_iter into pages from a previously completed command on the same tag, a use-after-free of those buffers that can be turned into an arbitrary read via heap reuse.
I:H - The copy is a use-after-free / wild write of attacker-chosen contents and length into reused kernel or page-cache memory, which is exploitable for arbitrary write and control-flow hijacking.
A:H - The same stale-iterator write was reproduced as a KASAN wild-memory-access in _copy_to_iter from nvme_tcp_io_work and can oops or panic the host kernel.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - The nvme-tcp host receive path parses C2HData PDUs from a remote NVMe/TCP target over a routable TCP connection (typically port 4420); a malicious or compromised target, or an on-path attacker injecting into the stream, triggers the bug from the network.
AC:L - A malicious target can advertise WRITE_ZEROES, wait for tag reuse after a data command, and send C2HData for that in-flight WRITE_ZEROES; leftover iterator state is deterministic because driver-private fields are not cleared on reuse, so no race or memory-layout luck is required.
PR:N - NVMe/TCP authentication (TLS, DH-HMAC-CHAP) is optional and off by default; the vulnerable copy runs on C2HData from the connected peer, which needs no credentials or privileges on the victim host.
UI:N - Once the host is connected to the target as persistent storage, ordinary filesystem and block I/O generate WRITE_ZEROES commands; the attacker sends the crafted PDU without any further victim action.
S:U - The stale-iterator write corrupts memory in the same host kernel security authority; this is not a VM, IOMMU, or sandbox boundary crossing.
C:H - nvme_tcp_recv_data() writes attacker-controlled C2HData through a leftover iov_iter into pages from a previously completed command on the same tag, a use-after-free of those buffers that can be turned into an arbitrary read via heap reuse.
I:H - The copy is a use-after-free / wild write of attacker-chosen contents and length into reused kernel or page-cache memory, which is exploitable for arbitrary write and control-flow hijacking.
A:H - The same stale-iterator write was reproduced as a KASAN wild-memory-access in _copy_to_iter from nvme_tcp_io_work and can oops or panic the host kernel.
CVSS 3.1