{"id":"CVE-2026-46135","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix race between ICReq handling and queue teardown\n\nnvmet_tcp_handle_icreq() updates queue->state after sending an\nInitialization Connection Response (ICResp…","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix race between ICReq handling and queue teardown\n\nnvmet_tcp_handle_icreq() updates queue->state after sending an\nInitialization Connection Response (ICResp…","severity":"critical","cvss":9.8,"cvssVector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","cwe":["CWE-362"],"vendor":"linux","product":"linux_kernel","affected":["linux_kernel >= 5.0, < 6.12.88","linux_kernel >= 6.13, < 6.18.30","linux_kernel >= 6.19, < 7.0.7","linux_kernel = 7.1"],"patched":["linux_kernel 7.0.7"],"published":"2026-05-28","updated":"2026-07-04","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-46135","references":[{"url":"https://git.kernel.org/stable/c/49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/5293a8882c549fab4a878bc76b0b6c951f980a61","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/5f0b95ef68ab9afba75b20eebf436130f80c161a","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/67e1aaf93b495c2f10bc8a5fbba575fbb7f449b6","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/dcfe4d1f7960e7d1c01642318f3aae1a604f8508","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"tags":["nvd"],"epss":0.00397,"epssPercentile":0.33746,"ingestedAt":"2026-07-04T12:56:09.406Z","slug":"CVE-2026-46135","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix race between ICReq handling and queue teardown\n\nnvmet_tcp_handle_icreq() updates queue->state after sending an\nInitialization Connection Response (ICResp), but it does so without\nserializing against target-side queue teardown.\n\nIf an NVMe/TCP host sends an Initialization Connection Request\n(ICReq) and immediately closes the connection, target-side teardown\nmay start in softirq context before io_work drains the already\nbuffered ICReq. In that case, nvmet_tcp_schedule_release_queue()\nsets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue\nreference under state_lock.\n\nIf io_work later processes that ICReq, nvmet_tcp_handle_icreq() can\nstill overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the\nDISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and\nallows a later socket state change to re-enter teardown and issue a\nsecond kref_put() on an already released queue.\n\nThe ICResp send failure path has the same problem. If teardown has\nalready moved the queue to DISCONNECTING, a send error can still\noverwrite the state with NVMET_TCP_Q_FAILED, again reopening the\nwindow for a second teardown path to drop the queue reference.\n\nFix this by serializing both post-send state transitions with\nstate_lock and bailing out if teardown has already started.\n\nUse -ESHUTDOWN as an internal sentinel for that bail-out path rather\nthan propagating it as a transport error like -ECONNRESET. Keep\nnvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before\nhonoring that sentinel so receive-side parsing stays quiesced until the\nexisting release path completes.\n\n## Affected\n\n- `linux_kernel >= 5.0, < 6.12.88`\n- `linux_kernel >= 6.13, < 6.18.30`\n- `linux_kernel >= 6.19, < 7.0.7`\n- `linux_kernel = 7.1`\n\n## Remediation\n\nUpgrade past the affected range:\n\n- `linux_kernel 7.0.7`","depth":"midnight","depthScore":54,"depthScoreParts":{"impact":53.9,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}