Description
In the Linux kernel, the following vulnerability has been resolved:

futex: Prevent rcuwait use-after-free during requeue PI

On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report
(slab-out-of-bounds) in futex_requeue_pi_complete() invocation of
rcuwait_wake_up().

The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's
stack. An early wakeup can race with a PI requeue as follows:

waiter requeue task
------ ------------
futex_wait_requeue_pi()
futex_do_wait()
schedule()
futex_requeue
futex_proxy_trylock_atomic()
futex_requeue_pi_prepare()
Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS
* timeout/ signal wakes waiter *
futex_requeue_pi_wakeup_sync()
Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT
requeue_pi_wake_futex
futex_requeue_pi_complete()
cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED
rcuwait_wait_event()
if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT)
break /* no schedule() */

/* q.pi_state->owner == current */
futex_private_hash_put()
/* return from syscall */
rcuwait_wake_up(&q->requeue_wait)
/* q is gone */

futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before
calling rcuwait_wake_up(). The waiter observes this state in
rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event().
Here, the waiter is free leave the syscall before requeue task can
complete the wake.

To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED
case.
This state is only published by requeue_pi_wake_futex(), which saves
q->task before futex_requeue_pi_complete() and wakes the waiter via
wake_up_state().

This wake is intended to wake the waiter from its futex_do_wait() sleep.
If the waiter is still sleeping there, it can not get into the
Q_REQUEUE_PI_WAIT state (and require this removed wake).
Should the waiter be woken up from futex_do_wait() by other means (as in
this example) and sleep in futex_requeue_pi_wakeup_sync() then the
wake_up_state() from requeue_pi_wake_futex() will wake it, too.
Should the waiter task terminate before wake_up_state() had a chance to
wake the task then the task pointer does not become invalid because the
futex_hash_bucket::lock is held and the task pointer is RCU protected.

[bigeasy: Updated comment and commit message]
Published: 2026-09-16
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Use‑After‑Free leading to kernel corruption and possible crash
Action: Patch
AI Analysis

Impact

A race condition exists in the Linux kernel’s futex requeue mechanism for Priority Inheritance (PI), specifically under the PREEMPT_RT kernel configuration. When a waiting task is woken prematurely while a requeue operation is in progress, the code may access memory for a futex queue that has already been freed. This triggers a KASAN slab‑out‑of‑bounds report and can corrupt kernel memory or cause a crash. The immediate impact is a denial of service or kernel panic, as the corrupted memory can lead to undefined behavior when used later in kernel execution. The vulnerability is a classic use‑after‑free and does not provide direct arbitrary code execution, but the extent of memory corruption could enable advanced attacks if an attacker can control the affected memory.

Affected Systems

All Linux distributions that use the standard Linux kernel compiled with the PREEMPT_RT patch set are potentially vulnerable. The affected code resides in the futex subsystem and applies to any kernel that lacks the fused patch fixing the rcuwait_wake_up logic. Versions older than the commit that introduced the mitigation are vulnerable.

Risk and Exploitability

The CVSS score of 7.8 reflects a high severity vulnerability that can lead to system instability. The EPSS score of less than 1% indicates a very low probability of exploitation at this time. The vulnerability is not listed in the CISA KEV catalog, suggesting no large‑scale public exploitation. Attack execution requires local access with the ability to trigger the specific racing condition between a waiting task and a requeue task, thus it is categorized as a local kernel exploitation scenario rather than a remote, publicly exploitable flaw.

Generated by OpenCVE AI on September 18, 2026 at 07:43 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that includes the patch for the futex requeue PI race condition.
  • Disable the PREEMPT_RT configuration or avoid enabling futex priority inheritance on critical paths until a patched kernel is available.
  • If an upgrade is not feasible, consider rebuilding the kernel with the corrected rcuwait_wake_up implementation or rely on the default kernel scheduling behavior without PI features.

Generated by OpenCVE AI on September 18, 2026 at 07:43 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Fri, 18 Sep 2026 08:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Wed, 16 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

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


Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: futex: Prevent rcuwait use-after-free during requeue PI On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message]
Title futex: Prevent rcuwait use-after-free during requeue PI
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-09-16T14:41:20.519Z

Reserved: 2026-09-11T19:38:34.780Z

Link: CVE-2026-90003

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:17:12.810

Modified: 2026-09-16T15:18:24.143

Link: CVE-2026-90003

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T07:45:05Z

Weaknesses