# CVE-2026-89482

## Summary

- **CVE ID:** CVE-2026-89482
- **Severity:** CRITICAL
- **CVSS Score:** 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
- **CWE:** N/A
- **Published:** Sep 11, 2026
- **Last Modified:** Sep 14, 2026

## 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.

## Affected Products

- Linux — Linux (25e5cb780e62bde432b401f312bb847edc78b432)
- Linux — Linux (f507ae6e33cbe56c4e3fe000434fc0ecc263d098)
- Linux — Linux (b1458c16f4e26e87492e58e4d24a1873bd09232a)
- Linux — Linux (5.4.36)
- Linux — Linux (5.6.8)
- Linux — Linux (5.7)
- Linux — Linux (0)
- Linux — Linux (6.12.109)
- Linux — Linux (6.18.50)
- Linux — Linux (7.2.4)
- Linux — Linux (7.3-rc1)
- Linux — Linux (5.10.270)
- Linux — Linux (5.15.221)
- Linux — Linux (6.1.188)
- Linux — Linux (6.6.157)

## References

- [CNA](https://git.kernel.org/stable/c/b36161701cb366f416afdcf70771d432a7c74753)
- [CNA](https://git.kernel.org/stable/c/6a01b58263108eaf9869bb6f82f07709240c6589)
- [CNA](https://git.kernel.org/stable/c/641ad3a30ba560f0a9a610376c568d7b75d2a2aa)
- [CNA](https://git.kernel.org/stable/c/3a4aa9e6ad3e35f8e24d5eaf38ee4d437075fb36)
- [CNA](https://git.kernel.org/stable/c/32ea8ce96b9bd797c59c351ce490ffd97adaa8c0)
- [CNA](https://git.kernel.org/stable/c/dd8906bb8f8d5bf1c9f861e1382c82b87bfe7cab)
- [CNA](https://git.kernel.org/stable/c/7ed0b61bbc145988be292c4d3ec580aebd8d2bcd)
- [CNA](https://git.kernel.org/stable/c/b96e1ff75e5c0ad6e077ac002b1d30b0a2b49528)

## Exploitation Prediction (EPSS)

- **EPSS Score:** 0.70%
- **EPSS Percentile:** 51.6

---
_Exported from OnDuty AI Vulnerability Intelligence on 2026-09-18._