DEBIAN-CVE-2026-46135

In the Linux kernel, the following vulnerability has been resolved:  nvmet-tcp: fix race between ICReq handling and queue teardown  nvmettcphandleicreq() 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 iowork drains the already buffered ICReq. In that case, nvmettcpschedulereleasequeue() sets queue->state to NVMETTCPQDISCONNECTING and drops the queue reference under statelock.  If iowork later processes that ICReq, nvmettcphandleicreq() can still overwrite the state back to NVMETTCPQLIVE. That defeats the DISCONNECTING-state guard in nvmettcpschedulereleasequeue() and allows a later socket state change to re-enter teardown and issue a second krefput() 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 NVMETTCPQFAILED, again reopening the window for a second teardown path to drop the queue reference.  Fix this by serializing both post-send state transitions with statelock 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 nvmettcpsocketerror() setting rcvstate to NVMETTCPRECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.