CVE-2026-89482

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.