cbcvebase.
CVE-2026-46135
published 2026-05-28

CVE-2026-46135: In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq()…

PriorityP352critical9.8CVSS 3.1
AVNACLPRNUINSUCHIHAH
EPSS
0.40%
32.3th percentile
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.

Affected

61 ranges· showing 25
VendorProductVersion rangeFixed in
linuxlinux
linuxlinux>= 872d26a391da92ed8f0c0f5cb5fef428067b7f30 < b7dd4d27aa70bd98bb10572310e913668baf6a65b7dd4d27aa70bd98bb10572310e913668baf6a65
linuxlinux>= 872d26a391da92ed8f0c0f5cb5fef428067b7f30 < 9c63cf80895a70eb4fcfcaa725bb1ac9ae76f02b9c63cf80895a70eb4fcfcaa725bb1ac9ae76f02b
linuxlinux>= 872d26a391da92ed8f0c0f5cb5fef428067b7f30 < 6f96dea4819d122737b217ea16660d255abbf8c66f96dea4819d122737b217ea16660d255abbf8c6
linuxlinux>= 872d26a391da92ed8f0c0f5cb5fef428067b7f30 < 5f0b95ef68ab9afba75b20eebf436130f80c161a5f0b95ef68ab9afba75b20eebf436130f80c161a
linuxlinux>= 872d26a391da92ed8f0c0f5cb5fef428067b7f30 < 49891c8fe0cb43fbbe480da1cdccfbbaeb820cb349891c8fe0cb43fbbe480da1cdccfbbaeb820cb3
linuxlinux>= 872d26a391da92ed8f0c0f5cb5fef428067b7f30 < 67e1aaf93b495c2f10bc8a5fbba575fbb7f449b667e1aaf93b495c2f10bc8a5fbba575fbb7f449b6
linuxlinux>= 872d26a391da92ed8f0c0f5cb5fef428067b7f30 < dcfe4d1f7960e7d1c01642318f3aae1a604f8508dcfe4d1f7960e7d1c01642318f3aae1a604f8508
linuxlinux>= 872d26a391da92ed8f0c0f5cb5fef428067b7f30 < 5293a8882c549fab4a878bc76b0b6c951f980a615293a8882c549fab4a878bc76b0b6c951f980a61
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 5.0 < 6.12.886.12.88
linuxlinux_kernel>= 6.13 < 6.18.306.18.30
linuxlinux_kernel>= 6.19 < 7.0.77.0.7
ubuntulinux
ubuntulinux-aws
ubuntulinux-aws-5.15
ubuntulinux-aws-6.8
ubuntulinux-aws-fips
ubuntulinux-azure
ubuntulinux-azure-5.15
ubuntulinux-azure-fde-5.15
ubuntulinux-azure-fips
ubuntulinux-fips
ubuntulinux-gcp

CVSS provenance

nvdv3.19.8CRITICALCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vendor_ubuntu8.8HIGH
vendor_redhat7.0HIGH
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.