CVE-2025-39977: futex: Prevent use-after-free during requeue-PI
In the Linux kernel, the following vulnerability has been resolved:
futex: Prevent use-after-free during requeue-PI
syzbot managed to trigger the following race:
T1 T2
futex_wait_requeue_pi()
futex_do_wait()
schedule()
futex_requeue()
futex_proxy_trylock_atomic()
futex_requeue_pi_prepare()
requeue_pi_wake_futex()
futex_requeue_pi_complete()
/* preempt */
* timeout/ signal wakes T1 *
futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED
futex_hash_put()
// back to userland, on stack futex_q is garbage
/* back */
wake_up_state(q->task, TASK_NORMAL);
In this scenario futex_wait_requeue_pi() is able to leave without using
futex_q::lock_ptr for synchronization.
This can be prevented by reading futex_q::task before updating the
futex_q::requeue_state. A reference on the task_struct is not needed
because requeue_pi_wake_futex() is invoked with a spinlock_t held which
implies a RCU read section.
Even if T1 terminates immediately after, the task_struct will remain valid
during T2's wake_up_state(). A READ_ONCE on futex_q::task before
futex_requeue_pi_complete() is enough because it ensures that the variable
is read before the state is updated.
Read futex_q::task before updating the requeue state, use it for the
following wakeup.
Security readout for executives and security teams
Plain-English summary
A race in Linux futex synchronization can let a local, low-privilege process access kernel data after its lifetime ends. Successful exploitation could compromise confidentiality, integrity, and availability. The flaw requires local access; the supplied evidence does not establish remote exploitation or attacks in the wild.
Executive priority
Treat as a high-priority local privilege-boundary issue. Accelerate patching on systems exposed to untrusted local code, while following normal change controls for kernel updates. The absence of documented active exploitation lowers immediate emergency pressure but does not remove the potentially severe impact.
Technical view
During priority-inheritance futex requeueing, a waiting thread can return and invalidate its stack-based futex_q while another thread still uses q->task for wakeup. The correction reads q->task before changing requeue_state and uses that saved value, preserving ordering while the held spinlock supplies the necessary RCU protection.
Likely exposure
Exposure applies to Linux systems running the listed affected versions, including 5.15, 6.1.155, 6.6.109, 6.12.50, 6.16.10, and 6.17. Risk is greatest where untrusted or compromised low-privilege users can execute locally. Distribution backports may change whether a nominally affected version remains vulnerable.
Exploitation context
CVSS 3.1 scores this 7.8: local access, low complexity, low privileges, and no user interaction, with potentially high impact. syzbot triggered the race during testing. The CVE is not identified as KEV, and the supplied sources provide no evidence of active exploitation.
Researcher notes
The vulnerable path involves futex_wait_requeue_pi racing futex_requeue and requeue_pi_wake_futex. The waiter may leave without lock_ptr synchronization, making its stack futex_q invalid before wake_up_state dereferences q->task. The fix relies on READ_ONCE ordering and the spinlock-implied RCU read section. No CWE was supplied.
Mitigation direction
Install a vendor-supported kernel containing the applicable upstream fix or distribution backport.
Check Linux distribution and appliance vendor advisories for package-specific remediation guidance.
Prioritize shared, multi-user, container-hosting, and untrusted-workload systems for remediation.
Review the cited Siemens advisories where affected Siemens products are deployed.
Validation and detection
Inventory running kernel versions across hosts and compare them with vendor advisories.
Confirm installed kernel packages include the relevant upstream fix or documented backport.
Verify systems booted into the remediated kernel after installation.
Reassess exposure wherever local low-privilege or untrusted workloads are permitted.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-39977 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
8Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.