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: 9.8 Critical
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 defect in error handling (CWE-1341) can lead to a use‑after‑free or kernel crash, resulting in denial of service.

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 9.8 and the EPSS score is < 1%.; 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.

Generated by OpenCVE AI on May 30, 2026 at 13:00 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 NVMe/TCP service is not required, unload the nvmet_tcp module or disable it in the kernel configuration to eliminate the attack surface.

Generated by OpenCVE AI on May 30, 2026 at 13:00 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 30 May 2026 11:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}


Fri, 29 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-1341
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Important


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-06-15T08:03:25.419Z

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-30T11:17:23.303

Link: CVE-2026-46135

cve-icon Redhat

Severity : Important

Publid Date: 2026-05-28T00:00:00Z

Links: CVE-2026-46135 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-30T13:00:12Z

Weaknesses
  • CWE-1341

    Multiple Releases of Same Resource or Handle