CVE-2026-46135

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: fix race between ICReq handling and queue teardown<br /> <br /> nvmet_tcp_handle_icreq() updates queue-&gt;state after sending an<br /> Initialization Connection Response (ICResp), but it does so without<br /> serializing against target-side queue teardown.<br /> <br /> If an NVMe/TCP host sends an Initialization Connection Request<br /> (ICReq) and immediately closes the connection, target-side teardown<br /> may start in softirq context before io_work drains the already<br /> buffered ICReq. In that case, nvmet_tcp_schedule_release_queue()<br /> sets queue-&gt;state to NVMET_TCP_Q_DISCONNECTING and drops the queue<br /> reference under state_lock.<br /> <br /> If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can<br /> still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the<br /> DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and<br /> allows a later socket state change to re-enter teardown and issue a<br /> second kref_put() on an already released queue.<br /> <br /> The ICResp send failure path has the same problem. If teardown has<br /> already moved the queue to DISCONNECTING, a send error can still<br /> overwrite the state with NVMET_TCP_Q_FAILED, again reopening the<br /> window for a second teardown path to drop the queue reference.<br /> <br /> Fix this by serializing both post-send state transitions with<br /> state_lock and bailing out if teardown has already started.<br /> <br /> Use -ESHUTDOWN as an internal sentinel for that bail-out path rather<br /> than propagating it as a transport error like -ECONNRESET. Keep<br /> nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before<br /> honoring that sentinel so receive-side parsing stays quiesced until the<br /> existing release path completes.