CVE-2026-46135: Linux Kernel Race Condition Vulnerability

CVE-2026-46135 Overview

CVE-2026-46135 is a race condition vulnerability in the Linux kernel's NVMe-over-TCP target driver (nvmet-tcp). The flaw exists in nvmet_tcp_handle_icreq(), which updates queue->state after sending an Initialization Connection Response (ICResp) without serializing against target-side queue teardown. A remote NVMe/TCP host that sends an Initialization Connection Request (ICReq) and immediately closes the connection can trigger concurrent state transitions, leading to a double kref_put() on an already released queue.

Critical Impact
The race condition enables a use-after-free style condition through duplicate reference count decrements on a freed NVMe/TCP target queue, potentially resulting in kernel memory corruption or denial of service on systems exposing NVMe-over-TCP targets.

Affected Products

Linux kernel nvmet-tcp (NVMe-over-TCP target) driver
Linux distributions shipping vulnerable kernel versions with NVMe-oF target support enabled
Storage systems and servers exposing NVMe-over-TCP targets

Discovery Timeline

2026-05-28 - CVE-2026-46135 published to NVD
2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46135

Vulnerability Analysis

The vulnerability resides in the NVMe-over-TCP target driver's connection initialization handling. When a host sends an ICReq and immediately closes the TCP connection, target-side teardown may begin in softirq context before io_work drains the buffered ICReq. The teardown path calls nvmet_tcp_schedule_release_queue(), which sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock.

If io_work later processes the buffered ICReq, nvmet_tcp_handle_icreq() overwrites the state back to NVMET_TCP_Q_LIVE. This defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue(). A subsequent socket state change re-enters teardown and issues a second kref_put() on a queue whose reference has already been released.

The ICResp send failure path contains the same defect. If teardown has already moved the queue to NVMET_TCP_Q_DISCONNECTING, a send error can overwrite the state with NVMET_TCP_Q_FAILED, reopening the window for a duplicate teardown.

Root Cause

The root cause is missing serialization between post-send state transitions in nvmet_tcp_handle_icreq() and concurrent queue teardown logic. State writes to queue->state occur outside state_lock, breaking the invariant that DISCONNECTING is a terminal state. This classifies as a Race Condition leading to a double-free of the queue reference count.

Attack Vector

A remote NVMe/TCP host with network access to a vulnerable target sends a valid ICReq frame and then immediately closes the TCP connection. Repeated connection attempts with this pattern can race the target's io_work handler against the socket teardown path, triggering the state overwrite and subsequent duplicate kref_put(). No authentication beyond standard NVMe-oF connection setup is required to reach the vulnerable code path.

The fix serializes both post-send state transitions with state_lock and bails out if teardown has already started, using -ESHUTDOWN as an internal sentinel rather than propagating it as a transport error such as -ECONNRESET. nvmet_tcp_socket_error() continues setting rcv_state to NVMET_TCP_RECV_ERR so receive-side parsing remains quiesced until the existing release path completes.

Detection Methods for CVE-2026-46135

Indicators of Compromise

Kernel oops, panic, or KASAN use-after-free reports referencing nvmet_tcp_release_queue_work, nvmet_tcp_schedule_release_queue, or kref_put call paths
Unexpected NVMe-over-TCP target queue disconnections coincident with rapid client connect-then-close patterns
System logs showing repeated short-lived NVMe/TCP sessions terminating immediately after ICReq exchange

Detection Strategies

Enable KASAN on test kernels to surface the double kref_put() on the released queue object during fuzzing or stress testing
Inventory hosts running NVMe-oF target services and identify kernel versions lacking the upstream fix commits referenced below
Monitor for crash dumps where the faulting context involves nvmet-tcp workqueue items and state_lock paths

Monitoring Recommendations

Collect kernel ring buffer output (dmesg) from NVMe-oF target hosts and alert on nvmet_tcp warnings or BUGs
Track NVMe/TCP listener connection rates and short-duration sessions that complete only the ICReq phase
Forward host telemetry and crash artifacts to a centralized data lake for correlation across the storage fleet

How to Mitigate CVE-2026-46135

Immediate Actions Required

Apply the upstream Linux kernel patches that serialize nvmet_tcp_handle_icreq() state transitions under state_lock
Restrict network reachability of NVMe-over-TCP target ports (default TCP/4420) to trusted storage initiators only
If patching is not immediate, disable the nvmet-tcp module on hosts that do not require NVMe-over-TCP target functionality

Patch Information

The fix is available in upstream Linux kernel commits. Review and apply the following:

Consume vendor-distributed kernels containing these commits and reboot affected target hosts.

Workarounds

Unload the nvmet_tcp kernel module on systems that do not export NVMe-over-TCP namespaces: modprobe -r nvmet_tcp
Place NVMe-over-TCP target endpoints behind network segmentation that permits only authenticated, trusted initiators
Disable any unused NVMe-oF target subsystems and ports via nvmetcli until patched kernels are deployed

bash

# Configuration example: remove the nvmet-tcp module if NVMe/TCP target is unused
sudo modprobe -r nvmet_tcp
# Prevent automatic load at boot
echo 'blacklist nvmet_tcp' | sudo tee /etc/modprobe.d/blacklist-nvmet-tcp.conf