CVE-2026-89482: Linux Kernel NVMe-TCP Buffer Overflow

CVE-2026-89482 Overview

CVE-2026-89482 is a Linux kernel vulnerability in the NVMe over TCP (nvme-tcp) transport driver. The flaw stems from the receive path accepting Controller-to-Host (C2HData) PDUs based solely on blk_rq_payload_bytes() without validating blk_rq_nr_phys_segments(). For REQ_OP_WRITE_ZEROES requests, which report non-zero payload bytes but carry no physical segments, the driver copies incoming data into an uninitialized iterator left behind by a previous command reusing the same tag. This triggers wild memory writes, as confirmed by KASAN reports showing writes to unmapped addresses inside _copy_to_iter().

Critical Impact
A malicious or malfunctioning NVMe/TCP target can trigger kernel memory corruption on connected hosts, leading to crashes or potential code execution.

Affected Products

Linux kernel with the nvme-tcp driver enabled
Systems acting as NVMe over TCP initiators
Distributions shipping kernels prior to the upstream fix commits referenced below

Discovery Timeline

2026-09-11 - CVE-2026-89482 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-89482

Vulnerability Analysis

The vulnerability resides in the NVMe/TCP initiator receive path. A prior fix, commit 25e5cb780e62 ("nvme-tcp: fix possible crash in write_zeroes processing"), established that blk_rq_payload_bytes() must only be consulted after checking blk_rq_nr_phys_segments(). That guard was applied to nvme_tcp_setup_cmd_pdu(), which records the validated length in req->data_len. The receive gate was not updated.

When a REQ_OP_WRITE_ZEROES request is issued, setup leaves req->iter untouched because the request has no physical segments. If the target then transmits a C2HData PDU for that tag, nvme_tcp_recv_data() proceeds to copy incoming payload into whatever iterator state the previous request on that tag left in the driver-private area. The driver-private area is zeroed only at tag-set allocation time, so residual pointers persist across command completions.

The KASAN report in the changelog shows the concrete failure: _copy_to_iter+0x642/0x1330 writes 512 bytes into a wild address (ffe728c2175dfa81) from the nvme_tcp_wq workqueue. This is an out-of-bounds write [CWE-787] driven by attacker-controlled data.

Root Cause

The receive-side validation was inconsistent with the send-side validation. blk_rq_payload_bytes() is unsafe for requests without physical segments, but the receive gate relied on it alone. Because req->data_len and req->curr_bio are driver-private and survive blk_update_request() completion, they cannot substitute for the check that rejects C2HData naming a tag that is no longer in flight.

Attack Vector

A network-reachable NVMe/TCP target, whether malicious or compromised, can craft a C2HData PDU targeting a tag associated with a WRITE_ZEROES command. Because the exploitation vector is network-based and requires no authentication beyond the existing NVMe/TCP session, an attacker able to impersonate or man-in-the-middle a target can corrupt kernel memory on the initiator.

No verified public exploit code is available. The vulnerability mechanism is described in the upstream commit messages linked in the references. See the Linux Kernel Commit Fix for the corrected receive-side gating logic.

Detection Methods for CVE-2026-89482

Indicators of Compromise

KASAN reports naming _copy_to_iter, nvme_tcp_recv_skb, or nvme_tcp_io_work in the call stack
Kernel oops or panic messages originating from the nvme_tcp_wq workqueue
Unexpected NVMe/TCP session resets or controller resets following WRITE_ZEROES operations
Kernel logs indicating memory corruption on hosts with active NVMe over TCP connections

Detection Strategies

Enable KASAN on test kernels to surface wild-memory-access writes in nvme-tcp code paths
Monitor kernel ring buffers for nvme_tcp_recv_data warnings or fatal errors
Inventory hosts running vulnerable kernels with the nvme_tcp module loaded and active sessions
Correlate crash telemetry with NVMe/TCP target endpoints to identify potentially malicious sources

Monitoring Recommendations

Alert on unexpected kernel crashes on systems using NVMe over TCP
Track NVMe/TCP session establishment to unauthorized or unmanaged targets
Capture network flow data between initiators and NVMe/TCP targets on TCP port 4420 for forensic review
Baseline normal NVMe/TCP traffic patterns and alert on anomalies in C2HData PDU volume or timing

How to Mitigate CVE-2026-89482

Immediate Actions Required

Apply the upstream kernel patches referenced below or update to a distribution kernel that includes them
Restrict NVMe/TCP connectivity to trusted storage targets only, using network segmentation or firewalling on TCP port 4420
Disable the nvme_tcp module on hosts that do not require NVMe over TCP connectivity
Audit existing NVMe/TCP sessions and validate that each connected target is authorized

Patch Information

The fix reintroduces the blk_rq_payload_bytes() check on the receive side and adds req->data_len to it, so the receive gate tests the same two conditions used during setup. Multiple stable-tree backports are available. See the following upstream commits: 641ad3a30ba5, b96e1ff75e5c, 6a01b5826310, 7ed0b61bbc14, b36161701cb3, dd8906bb8f8d, 32ea8ce96b9b, and 3a4aa9e6ad3e.

Workarounds

Unload the nvme_tcp kernel module where NVMe over TCP is not in use: modprobe -r nvme_tcp
Blocklist the module in /etc/modprobe.d/ to prevent automatic reload at boot
Use IPsec or TLS transport (nvme-tcp with TLS 1.3) between initiator and target to prevent man-in-the-middle injection of malicious C2HData PDUs
Isolate storage networks from general-purpose networks and restrict which hosts can reach NVMe/TCP targets

bash

# Disable nvme_tcp module until the host kernel is patched
sudo modprobe -r nvme_tcp
echo "blacklist nvme_tcp" | sudo tee /etc/modprobe.d/blacklist-nvme-tcp.conf

# Restrict inbound/outbound NVMe/TCP (port 4420) to authorized targets only
sudo iptables -A OUTPUT -p tcp --dport 4420 -d <trusted_target_ip> -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 4420 -j DROP