Skip to main content
VulnerabilityPublished Updated

CVE-2026-46135: Linux kernel · Race Condition

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 9.8 Critical · fixed in dcfe4d1f7960e7d1c01642318f3aae1a604f8508 : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 17:30 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 33% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in dcfe4d1f7960e7d1c01642318f3aae1a604f8508, b7dd4d27aa70bd98bb10572310e913668baf6a65, 49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3 +5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 28 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 872d26a391da92ed8f0c0f5cb5fef428067b7f30, < dcfe4d1f7960e7d1c01642318f3aae1a604f8508
Fixed in
  • dcfe4d1f7960e7d1c01642318f3aae1a604f8508
LinuxLinuxAffected
  • ≥ 872d26a391da92ed8f0c0f5cb5fef428067b7f30, < b7dd4d27aa70bd98bb10572310e913668baf6a65
Fixed in
  • b7dd4d27aa70bd98bb10572310e913668baf6a65
LinuxLinuxAffected
  • ≥ 872d26a391da92ed8f0c0f5cb5fef428067b7f30, < 49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3
Fixed in
  • 49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3
LinuxLinuxAffected
  • ≥ 872d26a391da92ed8f0c0f5cb5fef428067b7f30, < 5293a8882c549fab4a878bc76b0b6c951f980a61
Fixed in
  • 5293a8882c549fab4a878bc76b0b6c951f980a61
LinuxLinuxAffected
  • ≥ 872d26a391da92ed8f0c0f5cb5fef428067b7f30, < 67e1aaf93b495c2f10bc8a5fbba575fbb7f449b6
Fixed in
  • 67e1aaf93b495c2f10bc8a5fbba575fbb7f449b6
LinuxLinuxAffected
  • ≥ 872d26a391da92ed8f0c0f5cb5fef428067b7f30, < 9c63cf80895a70eb4fcfcaa725bb1ac9ae76f02b
Fixed in
  • 9c63cf80895a70eb4fcfcaa725bb1ac9ae76f02b

Description

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.

References

Community reviews

Loading reviews…