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:
<pre>
waiter requeue task
------ ------------
</pre>
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]
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The bug is reached only through the local futex(2) syscalls FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI into kernel/futex/requeue.c; there is no network, Bluetooth, or physical-device path.
AC:L - The attacker controls both sides of the race: a waiter thread using FUTEX_WAIT_REQUEUE_PI with an attacker-chosen timeout or signal, and a concurrent FUTEX_CMP_REQUEUE_PI from another thread, and can retry with CPU pinning until the waiter returns before rcuwait_wake_up() on PREEMPT_RT.
PR:L - Any unprivileged local user can invoke futex() with FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI; do_futex() and futex_requeue() perform no capability or credential checks, CONFIG_FUTEX_PI is default-y, and the path is reachable from containers without elevated privileges.
UI:N - The attacker's own threads perform the wait, timeout or signal, and PI requeue; no victim action such as mounting a filesystem or opening a file is required.
S:U - The use-after-free corrupts kernel memory (the waiter's stack-allocated futex_q and a type-confused task_struct) within the same kernel security authority; this is a standard local privilege-escalation issue, not a VM, IOMMU, or hypervisor escape.
C:H - This is a use-after-free of the waiter's stack-allocated futex_q.requeue_wait; rcuwait_wake_up() reads a stale, attacker-refilled task_struct pointer and dereferences it in try_to_wake_up(), enabling arbitrary kernel-memory disclosure.
I:H - The stale futex_q lives on the attacker's own kernel stack, which a following syscall can refill with controlled bytes, so rcuwait_wake_up() passes an attacker-chosen pointer into try_to_wake_up(), which writes task state and makes indirect scheduler calls, enabling privilege escalation.
A:H - In the unexploited case, rcuwait_wake_up() dereferences a wild pointer from reused stack memory and causes a kernel oops or panic; any use-after-free of this kind is a High availability impact.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is reached only through the local futex(2) syscalls FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI into kernel/futex/requeue.c; there is no network, Bluetooth, or physical-device path.
AC:L - The attacker controls both sides of the race: a waiter thread using FUTEX_WAIT_REQUEUE_PI with an attacker-chosen timeout or signal, and a concurrent FUTEX_CMP_REQUEUE_PI from another thread, and can retry with CPU pinning until the waiter returns before rcuwait_wake_up() on PREEMPT_RT.
PR:L - Any unprivileged local user can invoke futex() with FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI; do_futex() and futex_requeue() perform no capability or credential checks, CONFIG_FUTEX_PI is default-y, and the path is reachable from containers without elevated privileges.
UI:N - The attacker's own threads perform the wait, timeout or signal, and PI requeue; no victim action such as mounting a filesystem or opening a file is required.
S:U - The use-after-free corrupts kernel memory (the waiter's stack-allocated futex_q and a type-confused task_struct) within the same kernel security authority; this is a standard local privilege-escalation issue, not a VM, IOMMU, or hypervisor escape.
C:H - This is a use-after-free of the waiter's stack-allocated futex_q.requeue_wait; rcuwait_wake_up() reads a stale, attacker-refilled task_struct pointer and dereferences it in try_to_wake_up(), enabling arbitrary kernel-memory disclosure.
I:H - The stale futex_q lives on the attacker's own kernel stack, which a following syscall can refill with controlled bytes, so rcuwait_wake_up() passes an attacker-chosen pointer into try_to_wake_up(), which writes task state and makes indirect scheduler calls, enabling privilege escalation.
A:H - In the unexploited case, rcuwait_wake_up() dereferences a wild pointer from reused stack memory and causes a kernel oops or panic; any use-after-free of this kind is a High availability impact.
CVSS 3.1