Description
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 ]
Published: 2026-08-22
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Apply Kernel Patch
AI Analysis

Impact

The bug resides in the Linux kernel’s robust futex handling. During a robust unlock, the kernel clears the FUTEX_WAITERS flag and wakes one waiter, but if that waiter is terminated before it can acknowledge the wake, the kernel fails to relay the wake to subsequent waiters. The missing wake leaves later waiters sleeping indefinitely, which can cause application hang or system component stalling. The flaw is a race condition and does not provide code execution or privilege escalation.

Affected Systems

All Linux kernel configurations that enable robust futexes are potentially affected. The CVE does not list specific kernel versions; any distribution running a kernel that lacks the recent commits adding the extra wake logic to robust list exit processing remains vulnerable. The required patches are referenced in the kernel tree but may not yet be merged into all downstream releases.

Risk and Exploitability

The CVSS score is 5.5 and the EPSS score is < 1%, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires a local attacker who can use or spawn a process with a robust futex; it does not allow remote code execution but can cause denial of service. The attack vector is most likely that a local untrusted user or a compromised application can trigger the lock cycle and terminate a waiting thread. Because the flaw relies on timing, the probability of automatic exploitation is low, but for services that depend on robust futexes the risk remains moderate to high.

Generated by OpenCVE AI on August 25, 2026 at 13:59 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that includes the commit adding the extra wake logic to robust list exit processing.
  • If an upgrade is not immediately feasible, manually apply the upstream patch that implements the missing wakeup logic and rebuild the kernel.
  • Disable robust futex usage in critical application components or replace them with alternative synchronization primitives.
  • Implement application‑level timeouts or watchdog mechanisms to recover from hung futex waiters, ensuring that long‑running threads are restarted if they become unresponsive.

Generated by OpenCVE AI on August 25, 2026 at 13:59 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4777-1 linux security update
Debian DSA Debian DSA DSA-6466-1 linux security update
History

Tue, 25 Aug 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-367
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Sat, 22 Aug 2026 19:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Sat, 22 Aug 2026 15:45:00 +0000

Type Values Removed Values Added
Description 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 ]
Title futex: Prevent robust futex exit race some more
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-22T15:32:32.190Z

Reserved: 2026-08-15T05:44:03.924Z

Link: CVE-2026-74658

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-22T16:16:39.453

Modified: 2026-08-22T16:16:39.453

Link: CVE-2026-74658

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-22T00:00:00Z

Links: CVE-2026-74658 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-25T14:00:17Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

  • CWE-367

    Time-of-check Time-of-use (TOCTOU) Race Condition