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.
Published: 2026-05-28
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability is a race condition in the Linux kernel's NVMe/TCP implementation that allows an attacker to trigger a double reference count decrement on a target queue. An NVMe/TCP host can send an initialization request (ICReq) and close the connection before the target processes the message, causing the queue state to be overwritten and a second kref_put to execute on an already released queue. This can lead to a use‑after‑free or kernel crash, resulting in denial of service. The weakness is identified as a race condition (CWE‑362).

Affected Systems

Affected systems are Linux kernel installations that include the nvmet-tcp subsystem. The vulnerability exists in all kernel versions prior to the patch that serializes queue state changes and prevents double teardown. No specific version range is supplied, so any Linux kernel that implements nvmet‑tcp without this fix is affected. The flaw was addressed by the commit identified in the references.

Risk and Exploitability

The CVSS score is not publicly disclosed and the EPSS score is unavailable; the vulnerability is not listed in the CISA KEV catalog. Nonetheless, the potential for a kernel crash and its exploit vector over a network connection to the NVMe/TCP service make the risk high for systems exposed to untrusted hosts. An attacker would need to influence a client that connects to the target over NVMe/TCP, but does not require local privileges. While no exploit has been reported, the conditions for exploitation are within reach of a sophisticated adversary. Immediate remediation is recommended.

Generated by OpenCVE AI on May 28, 2026 at 12:49 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade to a kernel version that includes the nvmet‑tcp state lock changes (commit 49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3 or later).
  • If updating is not feasible, restrict access to the NVMe/TCP service to trusted hosts and monitor logs for abnormal socket resets or kernel panics.
  • If the kernel crashes, restart the affected system to restore service.

Generated by OpenCVE AI on May 28, 2026 at 12:49 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 28 May 2026 10:15:00 +0000

Type Values Removed Values Added
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.
Title nvmet-tcp: fix race between ICReq handling and queue teardown
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-28T09:35:49.828Z

Reserved: 2026-05-13T15:03:33.099Z

Link: CVE-2026-46135

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-28T10:16:29.060

Modified: 2026-05-28T13:44:01.663

Link: CVE-2026-46135

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-28T13:30:15Z

Weaknesses

No weakness.