CVE-2026-89482: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone

Is it exploited?

Not on CISA's list. CISA has not added it to the Known Exploited Vulnerabilities catalog as of 28 Oct 2026. If CISA adds it, this page shows it as known exploited.

How likely is exploitation in the next 30 days?

0.7%

EPSS score, percentile 53.6 of all scored records. A probability estimated by FIRST, not a report of exploitation.

How severe?

9.8 Critical

CVSS v3.1 base score, given by the CNA

What should I do?

CISA has set no required action, because the vulnerability is not in KEV.

The CVE record links no vendor advisory, patch or mitigation.

Which versions are affected?

Affected

• from 5.4.36 to before 5.5
• from 5.6.8 to before 5.7
• 5.7

Unaffected before 5.7; 5.10.270; 5.15.221; 6.1.188; 6.6.157; 6.12.109; and 3 more

Versions by product

Source: CISA KEV 2026.10.28, as of 28 Oct 2026; FIRST EPSS, as of 29 Oct 2026; CVE List, as of 29 Oct 2026. About the data.

What to do

Advisories and patches

The CVE record links no vendor advisory, patch or mitigation.

This summary is based on the CVE record as of 29 Oct 2026. Check the vendor's advisory before you act: affected versions and fixes can change.

Affected products and versions

As listed in the CVE record.

Versions not listed are: unaffected.

Versions not listed are: affected.

Versions the record lists as unaffected: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50, 7.2.4, 7.3.

Source: CVE List, as of 29 Oct 2026. About the data.

About this vulnerability

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. Th…

Summary: CVE record, as of 29 Oct 2026.

• CISA has not added CVE-2026-89482 to its Known Exploited Vulnerabilities (KEV) catalog, as of 28 Oct 2026.
• The CVE record was published on 11 Sep 2026.
• The CVE record carries a CVSS v3.1 base score of 9.8 (Critical), given by its CNA.
• FIRST's EPSS model puts the probability of exploitation in the next 30 days at 0.7% (percentile 53.6), as of 29 Oct 2026. EPSS is a statistical estimate, not a report of exploitation.
• CISA's SSVC assessment in the CVE record: exploitation none, automatable yes, technical impact total.

Source: CISA KEV 2026.10.28, as of 28 Oct 2026; CVE List, as of 29 Oct 2026; FIRST EPSS, as of 29 Oct 2026. About the data.

Description

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

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.

Source: CVE List, as of 29 Oct 2026. About the data.

Timeline

Known exploited Linux vulnerabilities

• CVE-2026-46300: Linux Kernel Missing Initialization of a Variable Vulnerability (added 28 Oct 2026)
• CVE-2025-39682: Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability (added 18 Sep 2026)
• CVE-2025-39964: Linux Kernel Race Condition Vulnerability (added 18 Sep 2026)
• CVE-2026-53266: Linux Kernel Out-of-Bounds Write Vulnerability (added 18 Sep 2026)
• CVE-2026-53362: Linux Kernel Unspecified Vulnerability (added 27 Aug 2026)