[CVE-2026-90003][MODERATE 7.0] futex: Prevent rcuwait use-after-free during requeue PI

[CVE-2026-90003][MODERATE 7.0] futex: Prevent rcuwait use-after-free during requeue PI

[AL-KERNEL]

CVE: CVE-2026-90003
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: futex: Prevent rcuwait use-after-free during requeue PI
Commit: 220ee9e04ca3b7f014c000264aa6c884f036c86e
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=220ee9e04ca3b7f014c000264aa6c884f036c86e
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90003
Analysis date: Wed, 16 Sep 2026 09:00:44 -0400
ActionableScore: 6
ActionableScore lower bound: 5
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-90003 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90003

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE 7.0
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-90003	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-90003 CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-362;*CWE-787;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'A use-after-free in the futex requeue PI path can occur on PREEMPT_RT because futex_requeue_pi_complete can call rcuwait_wake_up on q.requeue_wait after the waiter has left the syscall and the stack allocated futex_q is no longer valid. A local process can trigger the vulnerable path through FUTEX_CMP_REQUEUE_PI by racing an early wakeup from timeout or signal with a PI requeue operation. For the CVSS the PR:L is used because an unprivileged local process can reach the futex syscall path and can create waiter and requeue activity, while no network access is involved. The base impact is at least local denial of service via KASAN report or kernel crash. For the paranoid score, the UAF on a kernel stack object makes limited or full confidentiality and integrity impact defensible and the issue should be reviewed manually.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 6)	YES	OOB DANGER RACE UAF KPANIC  KPANIC INCREASED_TO_HIGH_BASED_ON_GUESSCVSS DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFKP	NO	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=6
ActionableScoreLower=5
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 5
* Conservative score: 5. No floor or cap changed the score.
* Raw paranoid score: 6
* Paranoid score: 6. No floor or cap changed the score.
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

2. Signal breakdown

Conservative positive signals:

* +2 Real UAF / lifetime violation. The patch directly establishes that `futex_requeue_pi_complete()` can call `rcuwait_wake_up(&q->requeue_wait)` after the waiter has returned from the syscall and the stack allocated `struct futex_q` is no longer valid.
* +1 Local unprivileged trigger. Futex operations are reachable through syscalls by a local process, and the described path can be built from waiter and requeue activity without host administrator privilege.
* +1 Reliable kernel crash / strong DoS. The commit reports a KASAN slab-out-of-bounds in `rcuwait_wake_up()`, and the stale stack object access is a realistic kernel crash condition.
* +1 Attacker-influenced repeatable lifetime manipulation. The same local attacker can create waiter and requeue activity, trigger timeout or signal wakeups, and repeatedly drive the relevant futex lifetime transition.

Conservative negative signals:

* 0 No hard-race penalty. The bug is a race, but the attacker can repeatedly attempt the relevant waiter, wakeup, and requeue sequence. The prompt requires more than the word race for a timing penalty.
* 0 No PREEMPT_RT rarity penalty. The issue is limited to PREEMPT_RT, but that is a concrete affected kernel configuration rather than evidence of host-admin-only reachability or physical-only hardware.

Paranoid additional signal:

* +1 Structured stale-object exploitation leverage. The stale object is not a passive buffer. It contains an active `rcuwait` synchronization object used by another task after the waiter's stack frame has ended. This does not prove controlled reclaim or arbitrary write, but it leaves meaningful unresolved post-lifetime behavior beyond a shallow crash-only dereference.

Material non-awarded signals:

* Controlled reclaim not demonstrated.
* Arbitrary kernel read or write not demonstrated.
* Callback or function pointer control not demonstrated.
* Remote reachability not established.
* Confidentiality and integrity points are not awarded as separate established consequences.
* Extra availability point not awarded because the same crash is already counted once.
* Concrete repeated release/refcount signal not awarded. There is no demonstrated second `put`, `release`, `free`, or refcount mutation on the exact same dangling reference.
* Weak LPE concern not separately awarded because the paranoid point already captures the unresolved structured stale-object leverage.
* CLASS_A not used because no controlled reclaim, directed corruption, demonstrated LPE, or arbitrary R/W primitive is established.

Repeated release/refcount checklist:

* First release can end lifetime: not applicable. The lifetime loss is stack-frame exit, not a first refcount release.
* Exact same reference survives: yes, `q` remains referenced by the requeue task after waiter syscall return.
* Second operation is a real lifetime/refcount mutation: no. `rcuwait_wake_up()` uses the stale synchronization object but is not a concrete second lifetime/refcount release.
* +1 Concrete repeated release/refcount awarded: no.
* Paranoid repeated-refcount leverage awarded: no.
* FLOOR 5 applied: no. Conservative score naturally reaches 5.

3. Reachability analysis

The evaluated attacker is a local user process. The complete trigger is through futex syscall behavior, specifically `FUTEX_CMP_REQUEUE_PI` combined with waiter activity and an early wakeup from timeout or signal. This is below host administrator privilege, so `HostAdminRequired=NO`.

No namespace-scoped capability is required for the futex syscall path, and no network namespace or delegated capability is material to the trigger. Therefore `NamespaceScopedPrivilege=NO`.

No prior privileged setup is established beyond running an affected PREEMPT_RT kernel. The attacker can instantiate the relevant futex waiter and requeue activity from local code. The race requires a specific interleaving, but it is repeatable in principle because the attacker can loop the syscall pattern and wakeup timing. There is no network vector and no special hardware requirement.

4. Primitive and severity interpretation

The exact primitive is a real use-after-lifetime of a stack allocated `struct futex_q`. The object is an active structured kernel object because its embedded `rcuwait` state is consumed by `rcuwait_wake_up()` from another task after the waiter has left the syscall.

This is broader than an ordinary stale cleanup dereference because the stale object is part of live synchronization between the waiter and requeue task. However, it is not a concrete repeated release/refcount UAF, and it is not CLASS_A because the patch does not establish controlled reclaim, arbitrary R/W, callback control, credential manipulation, or demonstrated privilege escalation.

PrimitiveClass is CLASS_B. The demonstrated consequence is KASAN slab-out-of-bounds and likely kernel crash, i.e. local DoS. The speculative consequence is stronger exploitation from a kernel stack UAF, but this remains unresolved rather than proven.

ImportantCandidate=YES because this is a locally reachable futex UAF involving an active synchronization object, with unresolved exploitation leverage beyond a trivial NULL dereference. ManualReview=REQUIRED for the same reason. AutoDowngradeAllowed=NO because automatically closing it as ordinary crash-only Moderate would discard a concrete local kernel lifetime primitive.

Likely operational severity is Actionable Moderate at minimum, with Strong Important candidate review justified for affected PREEMPT_RT kernels.

5. One-sentence report phrase

A local futex requeue PI race on PREEMPT_RT can let `futex_requeue_pi_complete()` use a stack allocated `futex_q` after the waiter returns from the syscall, causing a kernel crash and leaving unresolved UAF exploitation risk.

6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: this is a local unprivileged, race-based, real UAF in a core syscall path on PREEMPT_RT, involving an active synchronization object rather than a simple fixed stale buffer.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: futex: Prevent rcuwait use-after-free during requeue PI
Commit: 220ee9e04ca3b7f014c000264aa6c884f036c86e
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=220ee9e04ca3b7f014c000264aa6c884f036c86e

Commit description:

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]

Fixes: 07d91ef ("futex: Prevent requeue_pi() lock nesting issue on RT")
Signed-off-by: Yao Kai <yaokai34@huawei.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260901135453.3121948-3-bigeasy@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  kernel/futex/requeue.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=220ee9e04ca3b7f014c000264aa6c884f036c86e

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-90003 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-90003

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 5
  Paranoid ActionableScore: 6

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): MODERATE 7.0

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).