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
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.
- 🔗 git.kernel.org/stable/c/b7dd4d27aa70bd98bb10572310e91366…
- 🔗 git.kernel.org/stable/c/9c63cf80895a70eb4fcfcaa725bb1ac9…
- 🔗 git.kernel.org/stable/c/6f96dea4819d122737b217ea16660d25…
- 🔗 git.kernel.org/stable/c/5f0b95ef68ab9afba75b20eebf436130…
- 🔗 git.kernel.org/stable/c/49891c8fe0cb43fbbe480da1cdccfbba…
- 🔗 git.kernel.org/stable/c/67e1aaf93b495c2f10bc8a5fbba575fb…
- 🔗 git.kernel.org/stable/c/dcfe4d1f7960e7d1c01642318f3aae1a…
- 🔗 git.kernel.org/stable/c/5293a8882c549fab4a878bc76b0b6c95…
```Code``` unterstützt. Zero-Day & Vulnerability Intelligence Hub
Echtzeit-Tracking mit EPSS Exploit-Wahrscheinlichkeiten, Angriffsvektor-Decodern und KI-Patch-Anleitungen.
📊 Historien-Charts — Criticals-Trend · Vendors · EPSS-Verteilung
| Tier | CVEs | Anteil |
|---|---|---|
| ≥90 % | 725 | 0,2 % |
| ≥50 % | 3.222 | 0,9 % |
| ≥10 % | 22.089 | 5,9 % |
| <10 % | 347.507 | 93,0 % |
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
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),
Noch keine Analyse zu CVE-2026-46135
Sei der Erste: Einschätzung, Betroffenheit, Workaround oder PoC — mit Antworten im Thread.