CVE-2026-46135

Undergoing Analysis Undergoing Analysis - In Progress

Race Condition in Linux Kernel NVMe/TCP Target

Publication date: 2026-05-28

Last updated on: 2026-07-04

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-05-28

Last Modified

2026-07-04

Generated

2026-07-08

AI Q&A

2026-05-28

EPSS Evaluated

2026-07-06

NVD

CVE-2026-46135

EUVD

EUVD-2026-32762

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	7.1
linux	linux_kernel	From 6.13 (inc) to 6.18.30 (exc)
linux	linux_kernel	From 6.19 (inc) to 7.0.7 (exc)
linux	linux_kernel	From 5.0 (inc) to 6.12.88 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-362	The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

Attack-Flow Graph

Executive Summary

This vulnerability exists in the Linux kernel's nvmet-tcp component, specifically in the handling of Initialization Connection Requests (ICReq) and queue teardown processes.

The issue arises because nvmet_tcp_handle_icreq() updates the queue state after sending an Initialization Connection Response (ICResp) without properly synchronizing with the target-side queue teardown.

If an NVMe/TCP host sends an ICReq and immediately closes the connection, the target-side teardown may begin before the ICReq is fully processed. This can cause the queue state to be overwritten incorrectly, defeating safeguards designed to prevent multiple teardowns on the same queue.

As a result, the queue reference count may be decremented twice, potentially leading to use-after-free or other memory management issues.

The fix involves serializing state transitions with a lock and aborting operations if teardown has already started, preventing the race condition.

Impact Analysis

This vulnerability can lead to improper handling of NVMe/TCP queue states, which may cause memory corruption or instability in the Linux kernel's NVMe/TCP target implementation.

Such instability could result in system crashes, denial of service, or unpredictable behavior of storage services relying on NVMe/TCP.

If you are running a Linux system that acts as an NVMe/TCP target, this vulnerability could be exploited by a malicious or misbehaving NVMe/TCP host to disrupt service or cause kernel-level faults.

Mitigation Strategies

The vulnerability has been resolved by fixing the race condition in the Linux kernel's nvmet-tcp module. To mitigate this vulnerability, you should update your Linux kernel to a version that includes this fix.

The fix involves serializing post-send state transitions with state_lock and preventing state overwrites if teardown has already started, which prevents double queue release issues.

Hi! I’m here to help you understand CVE-2026-46135. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70