CVE-2026-46135Critical· 9.8▾ MidnightIn 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…
▾ Midnight zone — Critical, or high with PoC / in-the-wild
impact 53.9 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Aug 1.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.4%
0.4% → 0.6%
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.
linux_kernel >= 5.0, < 6.12.88linux_kernel >= 6.13, < 6.18.30linux_kernel >= 6.19, < 7.0.7linux_kernel = 7.1Upgrade past the affected range:
linux_kernel 7.0.7Connected by shared product, vendor, weakness, or advisory.
CVE-2022-3564Medium· 5.5A vulnerability classified as critical was found in Linux Kernel
CVE-2022-3521Low· 2.6A vulnerability has been found in Linux Kernel and classified as problematic
CVE-2022-3303Medium· 4.7A race condition flaw was found in the Linux kernel sound subsystem due to improper locking
CVE-2022-2959High· 7.0A race condition was found in the Linux kernel's watch queue due to a missing lock in pipe_resize_ring()
CVE-2022-3028High· 7.0A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously
CVE-2022-1462Medium· 6.3An out-of-bounds read flaw was found in the Linux kernel’s TeleTYpe subsystem