Back to CVE records
Critical 9.8Published May 28, 2026

CVE-2026-46135nvmet-tcp: fix race between ICReq handling and queue teardown

Updated under an hour ago ()

Does this affect you?

It affects Linux and 1 other product. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

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
9.8 CRITICAL (v3.1, CNA)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Weakness (CWE)
Not given
Known exploited
Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days)
Not loaded for this CVE
Assigned by
Linux
NVD analysis
Undergoing Analysis
Record last updated
Oct 16, 2026
First seen by InfoSec Signals
Oct 9, 2026

Affected products

Affected products
Linux Linux
linux:linux (from the name)
from 872d26a391da92ed8f0c0f5cb5fef428067b7f30 before b7dd4d27aa70bd98bb10572310e913668baf6a65; 872d26a391da92ed8f0c0f5cb5fef428067b7f30 builds before 9c63cf80895a70eb4fcfcaa725bb1ac9ae76f02b; 872d26a391da92ed8f0c0f5cb5fef428067b7f30 builds before 6f96dea4819d122737b217ea16660d255abbf8c6; 872d26a391da92ed8f0c0f5cb5fef428067b7f30 builds before 5f0b95ef68ab9afba75b20eebf436130f80c161a; from 872d26a391da92ed8f0c0f5cb5fef428067b7f30 before 49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3; 872d26a391da92ed8f0c0f5cb5fef428067b7f30 builds before 67e1aaf93b495c2f10bc8a5fbba575fbb7f449b6; from 872d26a391da92ed8f0c0f5cb5fef428067b7f30 before dcfe4d1f7960e7d1c01642318f3aae1a604f8508; from 872d26a391da92ed8f0c0f5cb5fef428067b7f30 before 5293a8882c549fab4a878bc76b0b6c951f980a61
CNA record
linux linux_kernel
linux:linux_kernel
from 5.0 before 6.12.88; from 6.13 before 6.18.30; from 6.19 before 7.0.7; 7.1
NVD

References

  • patch
  • patch
  • patch
  • patch

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.

Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.