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() 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.