CVE-2026-74658 — futex: Prevent robust futex exit race some more
In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit race"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ]
Who exploits it and how urgent it is
A 0–100 score combining confirmed exploitation, ransomware and APT use, public exploits, EPSS and severity.
How the score was calculated
- EPSS 0.2% (30-day exploitation probability)+1
The score orders the patch queue; it does not replace your asset context (internet exposure, criticality, compensating controls).
Triage
Is it exploited, how likely is exploitation, what does it touch, and how severe do the sources call it.
Remediation
Fixes and mitigations documented by the sources — linked to the original advisory.
No fix documented by the sources we poll. That does not mean none exists: check the vendor advisory.
First 24 hours
Ordered from the record’s own fields — exposure first, because you cannot patch what you have not found. A rule-generated starting point.
- Identify exposed assets running the affected vendor/product/version combinations (Linux Linux).
- No fix documented in the sources: reduce exposure and monitor the vendor advisory.
- Search available logs for exploit probes, errors and authentication anomalies.
Affected scope
Vendor, product and versions as the sources word them.
| Vendor | Product | Versions | Status | Source |
|---|---|---|---|---|
| Linux | Linux |
version 3e24098da750991f75819069c79e090dfd029219version 5.5≥ 5.4.1 and < 5.5≥ 5.3.14 and < 5.4≥ 4.19.87 and < 4.20≥ 4.14.158 and < 4.15≥ 4.9.264 and < 4.10≥ 3.16.82 and < 3.17 and 13 moreversion 82ca3ab31b9cf23b86436a85381e4c5757bc6b80version 2c60b44d8ba9d62c2693d2692f118177f212b1a8version 2819f4030f43057238992a4adcd950d7c95aff65≥ ca16d5bee59807bf04deaab0a8eccecd5061528c and < 83b0f71d5a313a765754acab51d2ecc5de76e0b9version b90aa237f469c3575190a5e6a855b76ad1d2ce94version 8dd558881e0f4d6942c19bd8f7b1a7c19becb59e≥ ca16d5bee59807bf04deaab0a8eccecd5061528c and < 6d4514ca9cdf61fec4ec634cf50386f6f7e69748≥ ca16d5bee59807bf04deaab0a8eccecd5061528c and < 7cf710e70f9bb8ea75f759ebed09871801315992≥ ca16d5bee59807bf04deaab0a8eccecd5061528c and < 7b8c53263f8878bdd12c87e147ac6feca5c05211≥ ca16d5bee59807bf04deaab0a8eccecd5061528c and < 925628656b73b70930972ccde421de4f758d8650≥ ca16d5bee59807bf04deaab0a8eccecd5061528c and < aa5c571901c6b22b58373693a4bf889ecab11ff5≥ ca16d5bee59807bf04deaab0a8eccecd5061528c and < 33bfa85458105d6169ebdb697f692b8bb8025bae≥ ca16d5bee59807bf04deaab0a8eccecd5061528c and < a1c2b7b86a946b6b172bce44d74553da2323a36c |
Vulnerable | CVE Program (cve.org) e CISA ADP |
EPSS over time FIRST
Oct 13, 2026 → Oct 14, 2026 · 2 reading(s) · max 0.18%
Detection
Read off the CVSS vector and the weakness class. Starting points, not tested rules.
- Not enough vector or weakness data: use the affected application’s logs as a starting point.
Timeline
What happened to this CVE, newest first.
- 2026
- Record published
- Affected products added · linux/linux
- Source status changed · → Received
- Record created in this database
- CVE published
Source activity
Repeated readings are counted rather than listed.
- 1× References added · Oct 14, 2026 – Oct 14, 2026
- 1× Official description updated · Oct 14, 2026 – Oct 14, 2026
References
10 on the record
- git.kernel.org/stable/c/a1c2b7b86a946b6b172bce44d74553da2323a36c
- git.kernel.org/stable/c/83b0f71d5a313a765754acab51d2ecc5de76e0b9
- nvd.nist.gov/vuln/detail/CVE-2026-74658
- git.kernel.org/stable/c/6d4514ca9cdf61fec4ec634cf50386f6f7e69748
- git.kernel.org/stable/c/925628656b73b70930972ccde421de4f758d8650
- git.kernel.org/stable/c/aa5c571901c6b22b58373693a4bf889ecab11ff5
- github.com/advisories/GHSA-m8rg-mx7q-fp2c
- git.kernel.org/stable/c/7b8c53263f8878bdd12c87e147ac6feca5c05211
- git.kernel.org/stable/c/7cf710e70f9bb8ea75f759ebed09871801315992
- git.kernel.org/stable/c/33bfa85458105d6169ebdb697f692b8bb8025bae
Elsewhere on this site
Related CVEs (same products)
- Critical CVE-2026-99999 ipv4: validate checksum_start before completing checksum 9h
- Unknown CVE-2026-98432 ipv4: free inet_opt and ireq_opt after an RCU grace period 9h
- Unknown CVE-2026-98428 ALSA: usb: 6fire: Avoid embedded URBs 1d
- Unknown CVE-2026-98431 RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency 1d
- Unknown CVE-2026-98430 RDMA/efa: Keep admin queues alive while IRQ is registered 1d
- Unknown CVE-2026-98429 RDMA/efa: Keep EQ resources alive while IRQ is registered 1d
Not in any source we poll
Listed rather than left blank: an empty field and an unmeasured one look identical on screen, and only one is a reason to look elsewhere.
- No CVSS score published by NVD, the CNA, CISA or GitHub so far.
- No fixed version, patch or mitigation documented.
- No CISA SSVC assessment.
- No CWE classification.
- No confirmed IOCs, IP addresses, domains, file hashes, or malware artifacts supplied.
- No organization-specific asset inventory, compensating-control status, or patch deployment evidence supplied.
- No exploit packet captures, log samples, or incident case IDs supplied.
Answered from this record
Text assembled only from the fields above — no additional claims.
What should defenders know first?
CVE-2026-74658 is "futex: Prevent robust futex exit race some more", rated Unknown. It affects Linux (Linux); versions are in the scope table. It is not in CISA KEV, which does not rule out exploitation. EPSS 0.18% estimates the probability of exploitation in 30 days; neither replaces your asset context. First verify whether exposed or business-critical assets run the affected versions, apply vendor fixes or mitigations, and preserve logs for review.
Comments
Moderated technical discussion. Read the community guidelines.
No comments yet.
Sign in or create an account to comment and suggest corrections.