EUVD-2026-38845
GHSA-f389-gw66-p7gf
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Race condition requires precise concurrent timing of signal delivery and requeue operation, warranting AC:H over NVD's AC:L; no confidentiality or integrity impact applies.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
5DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
futex: Prevent lockup in requeue-PI during signal/ timeout wakeup
During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen:
Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE
*blocks on hb->lock*
futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry*
Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B.
Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled.
As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic.
This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress.
Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().
AnalysisAI
Livelock in the Linux kernel's futex requeue-PI subsystem can hang a system when a signal or timeout interrupts a FUTEX_WAIT_REQUEUE_PI operation concurrently with an active FUTEX_CQ_REQUEUE_PI requeue. The race causes a waiting thread (Task A) to block indefinitely on a hash-bucket lock while a requeue thread (Task B) busy-loops retrying the same operation, consuming all available CPU - worst-case on uniprocessor systems where Task A cannot be scheduled at all. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires a local process invoking the FUTEX_WAIT_REQUEUE_PI futex operation (used internally by glibc when PTHREAD_PRIO_INHERIT mutex attributes are active), with a concurrent FUTEX_CQ_REQUEUE_PI call from a second thread in progress simultaneously. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The NVD CVSS score of 5.5 (Medium) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H correctly identifies local low-privileged exploitation with high availability impact and no confidentiality or integrity exposure. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A local unprivileged attacker creates multiple threads using FUTEX_WAIT_REQUEUE_PI and FUTEX_CQ_REQUEUE_PI, then arranges for a concurrent requeue operation from a higher-priority thread while delivering a signal to the waiting thread at the critical moment both hash-bucket locks are held. On a uniprocessor system or under SCHED_FIFO scheduling, the requeue thread enters an unbounded busy-loop while the waiting thread is starved of CPU time, causing the system to freeze. … |
| Remediation | Upgrade to a patched Linux kernel: 6.1.175 or later for the 6.1 LTS branch, 6.6.141 or later for the 6.6 LTS branch, 6.12.91 or later for 6.12, 6.18.33 or later for 6.18, 7.0.10 or later for 7.0, or 7.1 and later for the mainline branch. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today