CVE-2026-52989

What it actually does

This vulnerability affects the Linux kernel NVMe over Fabrics TCP target implementation (`nvmet-tcp`). When handling host-to-controller data PDUs, malformed PDU length or offset values can cause `nvmet_tcp_build_pdu_iovec()` to detect an invalid condition and mark the queue as fatally errored, but the error was not propagated to callers. Callers could then continue processing and transition the receive state as if the iterator had been initialized correctly, causing the TCP receive loop to read network data into an uninitialized message iterator. Depending on kernel configuration, memory layout, and reachable code path, this may result in kernel memory corruption, denial of service via kernel crash, or potentially more severe kernel-space impact.

Why it matters to the business

Systems exposing the Linux kernel NVMe/TCP target service may be vulnerable to a remote crash or kernel-level memory corruption triggered by malformed storage network traffic. In operational terms, this can disrupt storage availability, interrupt dependent workloads, and create risk for environments using NVMe-oF/TCP for block storage services. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at the time of assessment, but exposed storage targets should still be prioritized because kernel memory corruption in network-facing services can have high operational impact.

How an attack unfolds

An attacker must be able to reach a Linux host acting as an NVMe/TCP target. The attacker establishes or interacts with an NVMe/TCP connection and sends a crafted host-to-controller data PDU containing invalid length or offset values. The vulnerable kernel detects the malformed PDU and flags a fatal queue error, but because the helper function does not return an error to its callers, the caller may continue execution and set the queue receive state to receive data. The socket receive loop can then attempt to copy attacker-controlled network data through an uninitialized iterator, leading to memory corruption or a kernel fault. Public exploit maturity is currently reported as none, so exploitation should be treated as plausible but not confirmed as broadly weaponized.

How to fix it

Upgrade the Linux kernel to a version that includes the fix for `nvmet-tcp` error propagation from `nvmet_tcp_build_pdu_iovec()` to its callers. If vendor-specific fixed kernel versions are not yet available, track the relevant distribution advisories and apply the first kernel update containing this upstream fix. Where immediate patching is not possible, reduce exposure by disabling the NVMe/TCP target service if unused, unloading or preventing use of the `nvmet_tcp` module where operationally feasible, restricting access to NVMe/TCP ports to trusted initiators only, and isolating storage traffic on dedicated networks with firewall or fabric-level controls. Reboot or live-patch according to vendor guidance so the corrected kernel code is actually active.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for this issue, not merely that an updated package has been installed. Validate with `uname -r`, distribution package metadata, and vendor advisory references. Check whether the system exposes NVMe/TCP target functionality by reviewing loaded modules such as `nvmet_tcp`, NVMe target configuration, listening TCP services, and firewall rules. Where safe, confirm that NVMe/TCP access is limited to expected initiator addresses. After remediation, monitor for absence of kernel warnings, oopses, panics, or NVMe target queue fatal errors during normal NVMe/TCP operation.

Typical attack path

1. Identify Linux systems exposing NVMe over Fabrics TCP target functionality, typically on NVMe/TCP service ports such as TCP/4420 or organization-specific storage network ports.
2. Establish network connectivity to the NVMe/TCP target service from a host or compromised system with storage-network access.
3. Send crafted NVMe/TCP traffic containing malformed PDU length or offset fields that trigger the vulnerable error path.
4. Cause the target kernel to continue processing after the fatal queue condition, leaving the receive iterator uninitialized.
5. Trigger a receive operation that copies network data through the invalid iterator, potentially causing kernel memory corruption or a system crash.
6. Use the resulting disruption to impact storage availability, or in a more advanced scenario attempt to shape corruption for further kernel-level compromise.

How to detect it

To assess possible prior exploitation, review kernel logs, persistent journal data, crash dumps, and storage service logs on systems acting as NVMe/TCP targets. Focus on unexpected kernel oopses, panics, BUG or KASAN reports, general protection faults, invalid memory access messages, and NVMe target TCP fatal queue errors occurring near inbound NVMe/TCP connection attempts. Network telemetry should be reviewed for unexpected clients connecting to NVMe/TCP service ports, repeated short-lived sessions, malformed traffic, or spikes in connection resets. If kernel crash dumps are available, inspect stack traces for `nvmet_tcp_*` functions, especially receive-path functions and PDU handling. Because there are no public, stable exploit-specific artifacts currently known, detection should combine exposure analysis, kernel fault telemetry, and anomalous NVMe/TCP network activity rather than relying on a single signature.

• nvmet_tcp_build_pdu_iovec
• nvmet_tcp_handle_h2c_data_pdu
• nvmet_tcp_fatal_error
• NVMET_TCP_RECV_DATA
• nvmet_tcp
• nvmet-tcp
• nvmet_tcp:
• BUG: kernel NULL pointer dereference
• general protection fault
• Kernel panic - not syncing
• KASAN:
• Oops:
• TCP/4420

What your security team should do

• Inventory Linux systems that run NVMe over Fabrics TCP target services and determine whether `nvmet_tcp` is loaded or configured.
• Prioritize patching exposed storage targets, especially systems reachable from shared, untrusted, or broadly accessible networks.
• Apply vendor kernel updates as soon as available and reboot or otherwise activate the fixed kernel.
• Restrict NVMe/TCP access to trusted initiators and storage networks only; block unsolicited access to TCP/4420 and any custom NVMe/TCP ports.
• If NVMe/TCP target functionality is not required, disable the service and prevent the `nvmet_tcp` module from loading.
• Review kernel logs for recent crashes, oopses, queue fatal errors, or suspicious NVMe/TCP connection activity from unexpected hosts.
• Add monitoring for unexpected inbound NVMe/TCP connections and anomalous malformed or failed NVMe/TCP sessions.
• Track vendor advisories because exact fixed package versions vary by Linux distribution and kernel branch.