{"id":"CVE-2026-46135","summary":"nvmet-tcp: fix race between ICReq handling and queue teardown","details":"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-\u003estate 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-\u003estate 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.","modified":"2026-06-23T15:29:18.376248848Z","published":"2026-05-28T09:35:49.828Z","related":["ALSA-2026:27353","ALSA-2026:27354","ALSA-2026:27789","openSUSE-SU-2026:10954-1"],"database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46135.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3"},{"type":"WEB","url":"https://git.kernel.org/stable/c/5293a8882c549fab4a878bc76b0b6c951f980a61"},{"type":"WEB","url":"https://git.kernel.org/stable/c/67e1aaf93b495c2f10bc8a5fbba575fbb7f449b6"},{"type":"WEB","url":"https://git.kernel.org/stable/c/dcfe4d1f7960e7d1c01642318f3aae1a604f8508"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46135.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46135"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"872d26a391da92ed8f0c0f5cb5fef428067b7f30"},{"fixed":"49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3"},{"fixed":"67e1aaf93b495c2f10bc8a5fbba575fbb7f449b6"},{"fixed":"dcfe4d1f7960e7d1c01642318f3aae1a604f8508"},{"fixed":"5293a8882c549fab4a878bc76b0b6c951f980a61"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-46135.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.0.0"},{"fixed":"6.12.88"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.30"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.0.7"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-46135.json"}}],"schema_version":"1.7.5","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}