DEBIAN-CVE-2026-89482

In the Linux kernel, the following vulnerability has been resolved:  nvme-tcp: do not accept C2HData based on blkrqpayloadbytes() alone  Commit 25e5cb780e62 ("nvme-tcp: fix possible crash in writezeroes processing") established that blkrqpayloadbytes() must not be read without first checking blkrqnrphyssegments(), and recorded the result in nvmetcpsetupcmdpdu() as req->datalen. The receive side was left as it was.  The two differ for REQOPWRITEZEROES, 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 nvmetcprecvdata() 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 WRITEZEROES command on the same tag:  BUG: KASAN: wild-memory-access in copytoiter+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, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: nvmetcpwq nvmetcpiowork Call Trace:  <TASK>  dumpstacklvl+0x53/0x70  kasanreport+0xce/0x100  ? copytoiter+0x642/0x1330  kasancheckrange+0x105/0x1b0  asanmemcpy+0x3c/0x60  copytoiter+0x642/0x1330  ? pfxsockhasperm+0x10/0x10  ? workerthread+0x45b/0xd10  ? pfxcopytoiter+0x10/0x10  ? rawspinlockbh+0x83/0xe0  ? pfxrawspinlockbh+0x10/0x10  skbdatagramiter+0xf3/0x820  ? pfxsimplecopytoiter+0x10/0x10  ? asanmemcpy+0x3c/0x60  ? skbcopybits+0x58d/0x830  skbcopydatagramiter+0x37/0x120  nvmetcprecvskb+0xa07/0x4320  ? pfxnvmetcprecvskb+0x10/0x10  tcpreadsock+0x1ab/0x810  ? pfxnvmetcprecvskb+0x10/0x10  ? pfxlocksocknested+0x10/0x10  ? pfxtcpreadsock+0x10/0x10  nvmetcptryrecv+0x152/0x1e0  ? pfxnvmetcptryrecv+0x10/0x10  ? pfxmutexunlock+0x10/0x10  nvmetcpiowork+0x1e4/0x6c0  ? schedule+0x181a/0x49f0  ? pfxnvmetcpiowork+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.