CVE-2026-46135
Received Received - Intake
Race Condition in Linux Kernel NVMe/TCP Target

Publication date: 2026-05-28

Last updated on: 2026-05-28

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-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
CVE-2026-46135
EUVD
EUVD-2026-32762
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux_kernel nvmet_tcp *
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

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.


How can this vulnerability impact me? :

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.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart