[PATCH v3 0/2] futex: Address two futex-requeue-pi issues

[PATCH v3 0/2] futex: Address two futex-requeue-pi issues

[Sebastian Andrzej Siewior]

This is an update to Yao Kai initial series. I polished the commit
description and bit and update the comment in #2.

#1 Was simply missed in the initial commit and never noticed.
#2 Requires extreme precise timing to reproduce.

v2…v3: https://lore.kernel.org/20260722085140.1949077-1-yaokai34@huawei.com
 - Update commit message for both patches.
 - Drop the comment from #1. The whole thing has nothing to do with
   skipped schedule(). The only problem is that that rt_mutex_schedule()
   requires a rt_mutex_.*_schedule() invocation before rtmutex is about
   to be acquired. In case it went unnoticed for so long because that
   rt_mutex is usually not contended.
 - Update the comment in #2 to describe the race and why the wake is
   skipped.

v1…v2: (Yao Kai) https://lore.kernel.org/20260722085140.1949077-1-yaokai34@huawei.com
 - Replace the scheduler helper split in patch 1 with
   rt_mutex_pre_schedule()/rt_mutex_post_schedule() directly around
   rt_mutex_wait_proxy_lock().
 - Expand patch 2's comment and changelog to explain why the saved-task
   wakeup covers rcuwait without losing a wakeup.

Yao Kai (2):
  futex: Add missing rt_mutex_.*_schedule() around
    rt_mutex_wait_proxy_lock()
  futex: Prevent rcuwait use-after-free during requeue PI

 kernel/futex/requeue.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

Sebastian

[PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock()

[Sebastian Andrzej Siewior]

From: Yao Kai <yaokai34@huawei.com>

A waiter requeued onto a PI futex can reach rt_mutex_wait_proxy_lock()
without rtmutex schedule preparation, triggering the lockdep_assert() in
rt_mutex_schedule().
The lack of it, can be seen with requeue PI, multiple waiters and
requeing multiple tasks, the subsequent requeued task can be requeued in
the state Q_REQUEUE_PI_DONE:

        waiter                          requeue task
        ------                          ------------
futex_wait_requeue_pi()
  futex_wait_setup()
    futex_queue(&q)
                                        futex_requeue()
                                          futex_proxy_trylock_atomic()
                                          futex_requeue_pi_prepare()
                                           Q_REQUEUE_PI_NONE->Q_REQUEUE_PI_IN_PROGRESS

                                          rt_mutex_start_proxy_lock() (ret = 0)
                                          requeue_futex()
  futex_do_wait()
                                          futex_requeue_pi_complete()
                                            Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_DONE
  futex_requeue_pi_wakeup_sync()
  rt_mutex_wait_proxy_lock()
    rt_mutex_schedule() (on contention)

In the Q_REQUEUE_PI_DONE case the waiter will acquire the pi_mutex.
Should the lock be contended, the waiter will invoke rt_mutex_schedule()
without invoking rt_mutex_.*_schedule() before/ after scheduling.

Invoke rt_mutex_pre_schedule() and rt_mutex_post_schedule() directly around
rt_mutex_wait_proxy_lock().

[bigeasy: Redid parts of the changelog, dropped the comment misleading]

Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers")
Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Yao Kai <yaokai34@huawei.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 kernel/futex/requeue.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
index 79823ad136830..d8c9e7d218695 100644
--- a/kernel/futex/requeue.c
+++ b/kernel/futex/requeue.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 
 #include <linux/plist.h>
+#include <linux/sched/rt.h>
 #include <linux/sched/signal.h>
 
 #include "futex.h"
@@ -865,7 +866,10 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
 	case Q_REQUEUE_PI_DONE:
 		/* Requeue completed. Current is 'pi_blocked_on' the rtmutex */
 		pi_mutex = &q.pi_state->pi_mutex;
+
+		rt_mutex_pre_schedule();
 		ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter);
+		rt_mutex_post_schedule();
 
 		/*
 		 * See futex_unlock_pi()'s cleanup: comment.
-- 
2.55.0

[PATCH v3 2/2] futex: Prevent rcuwait use-after-free during requeue PI

[Sebastian Andrzej Siewior]

From: Yao Kai <yaokai34@huawei.com>

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: 07d91ef510fb1 ("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>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 kernel/futex/requeue.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
index d8c9e7d218695..6e98d5189f90a 100644
--- a/kernel/futex/requeue.c
+++ b/kernel/futex/requeue.c
@@ -155,8 +155,16 @@ static inline void futex_requeue_pi_complete(struct futex_q *q, int locked)
 	} while (!atomic_try_cmpxchg(&q->requeue_state, &old, new));
 
 #ifdef CONFIG_PREEMPT_RT
-	/* If the waiter interleaved with the requeue let it know */
-	if (unlikely(old == Q_REQUEUE_PI_WAIT))
+	/*
+	 * The waiter in futex_requeue_pi_wakeup_sync() can interleave with the
+	 * wake below: It will assign Q_REQUEUE_PI_IN_PROGRESS and here it will
+	 * be updated to Q_REQUEUE_PI_LOCKED (locked = 1). The rcuwait_wait_event()
+	 * will already read Q_REQUEUE_PI_LOCKED and skip the schedule() invocation,
+	 * leading to an access of futex_q::requeue_wait after the waiter returned.
+	 * In this case only we skip the wake here and rely on following wake in
+	 * requeue_pi_wake_futex() to perform the wake if needed.
+	 */
+	if (unlikely(old == Q_REQUEUE_PI_WAIT) && new != Q_REQUEUE_PI_LOCKED)
 		rcuwait_wake_up(&q->requeue_wait);
 #endif
 }
-- 
2.55.0

Re: [PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock()

[Peter Zijlstra]

On Mon, Aug 24, 2026 at 02:55:42PM +0200, Sebastian Andrzej Siewior wrote:
> From: Yao Kai <yaokai34@huawei.com>
> 
> A waiter requeued onto a PI futex can reach rt_mutex_wait_proxy_lock()
> without rtmutex schedule preparation, triggering the lockdep_assert() in
> rt_mutex_schedule().
> The lack of it, can be seen with requeue PI, multiple waiters and
> requeing multiple tasks, the subsequent requeued task can be requeued in
> the state Q_REQUEUE_PI_DONE:
> 
>         waiter                          requeue task
>         ------                          ------------
> futex_wait_requeue_pi()
>   futex_wait_setup()
>     futex_queue(&q)
>                                         futex_requeue()
>                                           futex_proxy_trylock_atomic()
>                                           futex_requeue_pi_prepare()
>                                            Q_REQUEUE_PI_NONE->Q_REQUEUE_PI_IN_PROGRESS
> 
>                                           rt_mutex_start_proxy_lock() (ret = 0)
>                                           requeue_futex()
>   futex_do_wait()
>                                           futex_requeue_pi_complete()
>                                             Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_DONE
>   futex_requeue_pi_wakeup_sync()
>   rt_mutex_wait_proxy_lock()
>     rt_mutex_schedule() (on contention)
> 
> In the Q_REQUEUE_PI_DONE case the waiter will acquire the pi_mutex.
> Should the lock be contended, the waiter will invoke rt_mutex_schedule()
> without invoking rt_mutex_.*_schedule() before/ after scheduling.
> 
> Invoke rt_mutex_pre_schedule() and rt_mutex_post_schedule() directly around
> rt_mutex_wait_proxy_lock().

Still doesn't explain why this is makes sense. Perhaps something like
the below comment to demystify the code?

> [bigeasy: Redid parts of the changelog, dropped the comment misleading]
> 
> Fixes: d14f9e930b90 ("locking/rtmutex: Use rt_mutex specific scheduler helpers")
> Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Yao Kai <yaokai34@huawei.com>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  kernel/futex/requeue.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
> index 79823ad136830..d8c9e7d218695 100644
> --- a/kernel/futex/requeue.c
> +++ b/kernel/futex/requeue.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-or-later
>  
>  #include <linux/plist.h>
> +#include <linux/sched/rt.h>
>  #include <linux/sched/signal.h>
>  
>  #include "futex.h"
> @@ -865,7 +866,10 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
>  	case Q_REQUEUE_PI_DONE:
>  		/* Requeue completed. Current is 'pi_blocked_on' the rtmutex */
>  		pi_mutex = &q.pi_state->pi_mutex;
> +

		/*
		 * Since current is doing the requeue, it cannot also be
		 * a waiter on the same futex.
		 */

> +		rt_mutex_pre_schedule();
>  		ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter);
> +		rt_mutex_post_schedule();
>  
>  		/*
>  		 * See futex_unlock_pi()'s cleanup: comment.
> -- 
> 2.55.0
> 

Re: [PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock()

[Sebastian Andrzej Siewior]

On 2026-08-24 15:23:34 [+0200], Peter Zijlstra wrote:
> Still doesn't explain why this is makes sense. Perhaps something like
> the below comment to demystify the code?

I'm sorry. Could you please peek at 20260824140809.eJxsIRHn@linutronix.de ?

Sebastian

Re: [PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock()

[Thomas Gleixner]

On Mon, Aug 24 2026 at 15:23, Peter Zijlstra wrote:
> On Mon, Aug 24, 2026 at 02:55:42PM +0200, Sebastian Andrzej Siewior wrote:
>>  #include "futex.h"
>> @@ -865,7 +866,10 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
>>  	case Q_REQUEUE_PI_DONE:
>>  		/* Requeue completed. Current is 'pi_blocked_on' the rtmutex */
>>  		pi_mutex = &q.pi_state->pi_mutex;
>> +
>
> 		/*
> 		 * Since current is doing the requeue, it cannot also be
> 		 * a waiter on the same futex.
> 		 */

Current is not the task doing the requeue. Current is the requeued waiter which is
blocked on the rtmutex.

Though the change log is confusing at best. The whole requeue explanation
is not really helpful IMO.

The point is that _all_ invocations of rt_mutex_schedule() must be
preceeded by a call to rt_mutex_pre_schedule() and followed by a call to
rt_mutex_post_schedule().

So this code simply failed to do that, which triggers the
lockdep_assert() in rt_mutex_schedule().

And it's obvious from the surrounding comments how this task got there, no?

>> +		rt_mutex_pre_schedule();
>>  		ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter);
>> +		rt_mutex_post_schedule();
>>  
>>  		/*
>>  		 * See futex_unlock_pi()'s cleanup: comment.
>> -- 
>> 2.55.0
>> 

Re: [PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock()

[Sebastian Andrzej Siewior]

On 2026-08-26 20:06:11 [+0200], Thomas Gleixner wrote:
> On Mon, Aug 24 2026 at 15:23, Peter Zijlstra wrote:
> > On Mon, Aug 24, 2026 at 02:55:42PM +0200, Sebastian Andrzej Siewior wrote:
> >>  #include "futex.h"
> >> @@ -865,7 +866,10 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
> >>  	case Q_REQUEUE_PI_DONE:
> >>  		/* Requeue completed. Current is 'pi_blocked_on' the rtmutex */
> >>  		pi_mutex = &q.pi_state->pi_mutex;
> >> +
> >
> > 		/*
> > 		 * Since current is doing the requeue, it cannot also be
> > 		 * a waiter on the same futex.
> > 		 */
> 
> Current is not the task doing the requeue. Current is the requeued waiter which is
> blocked on the rtmutex.
> 
> Though the change log is confusing at best. The whole requeue explanation
> is not really helpful IMO.
> 
> The point is that _all_ invocations of rt_mutex_schedule() must be
> preceeded by a call to rt_mutex_pre_schedule() and followed by a call to
> rt_mutex_post_schedule().
> 
> So this code simply failed to do that, which triggers the
> lockdep_assert() in rt_mutex_schedule().
> 
> And it's obvious from the surrounding comments how this task got there, no?

I would suggest to strip it all from the futex part, not do the flush
and just please the assert so it keeps quiet. I did some explaining in
the v2 and then Yao suggested
	https://lore.kernel.org/all/5df8a43e-11bb-4881-877d-40034c414984@huawei.com/

which is what I had in mind.

Sebastian

Re: [PATCH v3 1/2] futex: Add missing rt_mutex_.*_schedule() around rt_mutex_wait_proxy_lock()

[Thomas Gleixner]

On Thu, Aug 27 2026 at 10:37, Sebastian Andrzej Siewior wrote:
> On 2026-08-26 20:06:11 [+0200], Thomas Gleixner wrote:
>> On Mon, Aug 24 2026 at 15:23, Peter Zijlstra wrote:
>> > On Mon, Aug 24, 2026 at 02:55:42PM +0200, Sebastian Andrzej Siewior wrote:
>> >>  #include "futex.h"
>> >> @@ -865,7 +866,10 @@ int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
>> >>  	case Q_REQUEUE_PI_DONE:
>> >>  		/* Requeue completed. Current is 'pi_blocked_on' the rtmutex */
>> >>  		pi_mutex = &q.pi_state->pi_mutex;
>> >> +
>> >
>> > 		/*
>> > 		 * Since current is doing the requeue, it cannot also be
>> > 		 * a waiter on the same futex.
>> > 		 */
>> 
>> Current is not the task doing the requeue. Current is the requeued waiter which is
>> blocked on the rtmutex.
>> 
>> Though the change log is confusing at best. The whole requeue explanation
>> is not really helpful IMO.
>> 
>> The point is that _all_ invocations of rt_mutex_schedule() must be
>> preceeded by a call to rt_mutex_pre_schedule() and followed by a call to
>> rt_mutex_post_schedule().
>> 
>> So this code simply failed to do that, which triggers the
>> lockdep_assert() in rt_mutex_schedule().
>> 
>> And it's obvious from the surrounding comments how this task got there, no?
>
> I would suggest to strip it all from the futex part, not do the flush
> and just please the assert so it keeps quiet. I did some explaining in
> the v2 and then Yao suggested
> 	https://lore.kernel.org/all/5df8a43e-11bb-4881-877d-40034c414984@huawei.com/

That makes sense.