GHSA-pp4w-65w8-f5f3 · Severity: critical — In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between...
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.
Conclusion & alert: CVE-2026-46135 is rated Moderate Risk (45.5/100): CVSS Critical severity, with low exploitation likelihood (EPSS 0.06%). Mandatory action: Review affected assets and schedule remediation.
Risk is dynamic; we continuously reassess and refresh what is shown on this page as upstream context changes.
EPSS lead: Daily EPSS estimates relative likelihood of exploitation; percentile ranks this CVE among scored vulnerabilities (higher = more severe relative rank).
| # | Date | Old EPSS score | New EPSS score | Delta (New - Old) |
|---|---|---|---|---|
| 1 | 2026-05-30 | 0.02% | 0.06% | +0.04% |
| 2 | 2026-05-28 | — | 0.02% | — |
Full EPSS history (2 records total)
CVSS metrics for this CVE.
| Base score | Version | Severity | Vector | Exploitability | Impact | Score source |
|---|---|---|---|---|---|---|
| 9.8 | 3.1 | CRITICAL |
|
3.9 | 5.9 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
GHSA-pp4w-65w8-f5f3 · Severity: critical — In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between...
| vendor | priority | summary | link |
|---|---|---|---|
debian
|
not yet assigned | CVE-2026-46135 not yet assigned priority: Debian including 1 source packages (linux), 5 status rows across 5 suites (bookworm, bullseye, forky, sid, trixie): resolved 3, open 2. | https://security-tracker.debian.org/tracker/CVE-2026-46135 |
redhat
|
high | — | https://access.redhat.com/security/cve/CVE-2026-46135 |
suse
|
critical | — | https://www.suse.com/security/cve/CVE-2026-46135/ |
ubuntu
|
medium | CVE-2026-46135 medium priority: Ubuntu including 158 source packages (linux, linux-allwinner-5.19, …), 1422 status rows across 9 suites (bionic, focal, jammy, noble, questing, resolute, trusty, upstream, xenial): DNE 1024, needed 225, ignored 173. | https://ubuntu.com/security/CVE-2026-46135 |
| Vendor | Product | Version | Raw CPE |
|---|---|---|---|
| No affected products in dataset. | |||