CVE-2026-89482

In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: do not accept C2HData based on blkrqpayload_bytes() alone

Commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes

processing") established that blkrqpayload_bytes() must not be read

without first checking blkrqnrphyssegments(), and recorded the

result in nvmetcpsetupcmdpdu() as req->data_len. The receive side

was left as it was.

The two differ for REQOPWRITE_ZEROES, which has no physical segments

but a non-zero blkrqbytes(), so setup leaves req->iter untouched

while the receive gate lets a C2HData through and nvmetcprecv_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 copyto_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: nvmetcpwq nvmetcpio_work

Call Trace:

 <TASK>

 dumpstacklvl+0x53/0x70

 kasan_report+0xce/0x100

 ? copyto_iter+0x642/0x1330

 kasancheckrange+0x105/0x1b0

 _asanmemcpy+0x3c/0x60

 copyto_iter+0x642/0x1330

 ? _pfxsockhasperm+0x10/0x10

 ? worker_thread+0x45b/0xd10

 ? pfxcopytoiter+0x10/0x10

 ? rawspinlockbh+0x83/0xe0

 ? pfxrawspinlock_bh+0x10/0x10

 _skbdatagram_iter+0xf3/0x820

 ? _pfxsimplecopyto_iter+0x10/0x10

 ? _asanmemcpy+0x3c/0x60

 ? skbcopybits+0x58d/0x830

 skbcopydatagram_iter+0x37/0x120

 nvmetcprecv_skb+0xa07/0x4320

 ? _pfxnvmetcprecv_skb+0x10/0x10

 _tcpread_sock+0x1ab/0x810

 ? _pfxnvmetcprecv_skb+0x10/0x10

 ? _pfxlocksocknested+0x10/0x10

 ? pfxtcpread_sock+0x10/0x10

 nvmetcptry_recv+0x152/0x1e0

 ? _pfxnvmetcptry_recv+0x10/0x10

 ? _pfxmutex_unlock+0x10/0x10

 nvmetcpio_work+0x1e4/0x6c0

 ? __schedule+0x181a/0x49f0

 ? _pfxnvmetcpio_work+0x10/0x10

 processonework+0x633/0x1030

Keep the blkrqpayloadbytes() test and add req->datalen to it. The

old test is what rejects a C2HData naming a tag that is no longer in

flight, because blkupdaterequest() zeroes rq->_datalen on

completion; req->datalen and req->currbio are driver-private and

survive completion, so they cannot stand in for it. Setup initialises

the iterator only when both req->currbio and req->datalen are set, so

the gate now tests the same two.