FAILED: patch "[PATCH] rtmutex: Use waiter::task instead of current in" failed to apply to 5.15-stable tree

FAILED: patch "[PATCH] rtmutex: Use waiter::task instead of current in" failed to apply to 5.15-stable tree

[gregkh]

The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026050433-granular-zookeeper-b705@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 Mon Sep 17 00:00:00 2001
From: Keenan Dong <keenanat2000@gmail.com>
Date: Wed, 8 Apr 2026 16:46:00 +0800
Subject: [PATCH] rtmutex: Use waiter::task instead of current in
 remove_waiter()

remove_waiter() is used by the slowlock paths, but it is also used for
proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from
futex_requeue().

In the latter case waiter::task is not current, but remove_waiter()
operates on current for the dequeue operation. That results in several
problems:

  1) the rbtree dequeue happens without waiter::task::pi_lock being held

  2) the waiter task's pi_blocked_on state is not cleared, which leaves a
     dangling pointer primed for UAF around.

  3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter
     task

Use waiter::task instead of current in all related operations in
remove_waiter() to cure those problems.

[ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the
  	changelog ]

Fixes: 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Keenan Dong <keenanat2000@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: stable@vger.kernel.org

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index ccaba6148b61..4f386ea6c792 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1544,6 +1544,8 @@ static bool rtmutex_spin_on_owner(struct rt_mutex_base *lock,
  *
  * Must be called with lock->wait_lock held and interrupts disabled. It must
  * have just failed to try_to_take_rt_mutex().
+ *
+ * When invoked from rt_mutex_start_proxy_lock() waiter::task != current !
  */
 static void __sched remove_waiter(struct rt_mutex_base *lock,
 				  struct rt_mutex_waiter *waiter)
@@ -1551,14 +1553,15 @@ static void __sched remove_waiter(struct rt_mutex_base *lock,
 {
 	bool is_top_waiter = (waiter == rt_mutex_top_waiter(lock));
 	struct task_struct *owner = rt_mutex_owner(lock);
+	struct task_struct *waiter_task = waiter->task;
 	struct rt_mutex_base *next_lock;
 
 	lockdep_assert_held(&lock->wait_lock);
 
-	raw_spin_lock(&current->pi_lock);
-	rt_mutex_dequeue(lock, waiter);
-	current->pi_blocked_on = NULL;
-	raw_spin_unlock(&current->pi_lock);
+	scoped_guard(raw_spinlock, &waiter_task->pi_lock) {
+		rt_mutex_dequeue(lock, waiter);
+		waiter_task->pi_blocked_on = NULL;
+	}
 
 	/*
 	 * Only update priority if the waiter was the highest priority
@@ -1594,7 +1597,7 @@ static void __sched remove_waiter(struct rt_mutex_base *lock,
 	raw_spin_unlock_irq(&lock->wait_lock);
 
 	rt_mutex_adjust_prio_chain(owner, RT_MUTEX_MIN_CHAINWALK, lock,
-				   next_lock, NULL, current);
+				   next_lock, NULL, waiter_task);
 
 	raw_spin_lock_irq(&lock->wait_lock);
 }

[PATCH 5.15.y] rtmutex: Use waiter::task instead of current in remove_waiter()

[Sid Kumar]

From: Keenan Dong <keenanat2000@gmail.com>

remove_waiter() is used by the slowlock paths, but it is also used for
proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from
futex_requeue().

In the latter case waiter::task is not current, but remove_waiter()
operates on current for the dequeue operation. That results in several
problems:

  1) the rbtree dequeue happens without waiter::task::pi_lock being held

  2) the waiter task's pi_blocked_on state is not cleared, which leaves a
     dangling pointer primed for UAF around.

  3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter
     task

Use waiter::task instead of current in all related operations in
remove_waiter() to cure those problems.

[ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the
  	changelog ]

[ sidk: Replace scoped_guard() macro with raw spinlock operations for
	5.15]

Fixes: 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Keenan Dong <keenanat2000@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: stable@vger.kernel.org
(cherry picked from commit 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349)
Signed-off-by: Sid Kumar <sidkumar1@gmail.com>
---
 kernel/locking/rtmutex.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index cf72ef77bfe7..f79c9286c7c0 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1500,20 +1500,23 @@ static bool rtmutex_spin_on_owner(struct rt_mutex_base *lock,
  *
  * Must be called with lock->wait_lock held and interrupts disabled. It must
  * have just failed to try_to_take_rt_mutex().
+ *
+ * When invoked from rt_mutex_start_proxy_lock() waiter::task != current !
  */
 static void __sched remove_waiter(struct rt_mutex_base *lock,
 				  struct rt_mutex_waiter *waiter)
 {
 	bool is_top_waiter = (waiter == rt_mutex_top_waiter(lock));
 	struct task_struct *owner = rt_mutex_owner(lock);
+	struct task_struct *waiter_task = waiter->task;
 	struct rt_mutex_base *next_lock;
 
 	lockdep_assert_held(&lock->wait_lock);
 
-	raw_spin_lock(&current->pi_lock);
+	raw_spin_lock(&waiter_task->pi_lock);
 	rt_mutex_dequeue(lock, waiter);
-	current->pi_blocked_on = NULL;
-	raw_spin_unlock(&current->pi_lock);
+	waiter_task->pi_blocked_on = NULL;
+	raw_spin_unlock(&waiter_task->pi_lock);
 
 	/*
 	 * Only update priority if the waiter was the highest priority
@@ -1549,7 +1552,7 @@ static void __sched remove_waiter(struct rt_mutex_base *lock,
 	raw_spin_unlock_irq(&lock->wait_lock);
 
 	rt_mutex_adjust_prio_chain(owner, RT_MUTEX_MIN_CHAINWALK, lock,
-				   next_lock, NULL, current);
+				   next_lock, NULL, waiter_task);
 
 	raw_spin_lock_irq(&lock->wait_lock);
 }
-- 
2.52.0

Re: [PATCH 5.15.y] rtmutex: Use waiter::task instead of current in remove_waiter()

[Sasha Levin]

> Use waiter::task instead of current in all related operations in
> remove_waiter() to cure those problems.
>
> [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the
> 	changelog ]
>
> [ sidk: Replace scoped_guard() macro with raw spinlock operations for
> 	5.15]

The backport itself looks correct, but I can't take it alone: upstream
this commit has a Cc: stable follow-up fix, 40a25d59e85b3c
("locking/rtmutex: Skip remove_waiter() when waiter is not enqueued").

Could you resend this as a two-patch series: this patch plus a 5.15.y
adaptation of 40a25d59e85b3c? Also worth considering as a third patch is
74e144274af399 ("futex/requeue: Prevent NULL pointer dereference in
remove_waiter() on self-deadlock").

-- 
Thanks,
Sasha

Re: [PATCH 5.15.y] rtmutex: Use waiter::task instead of current in remove_waiter()

[Wu Frank]

On Wed, Jul 8, 2026 at 6:04 PM Sasha Levin <sashal@kernel.org> wrote:
>
> > Use waiter::task instead of current in all related operations in
> > remove_waiter() to cure those problems.
> >
> > [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the
> >       changelog ]
> >
> > [ sidk: Replace scoped_guard() macro with raw spinlock operations for
> >       5.15]
>
> The backport itself looks correct, but I can't take it alone: upstream
> this commit has a Cc: stable follow-up fix, 40a25d59e85b3c
> ("locking/rtmutex: Skip remove_waiter() when waiter is not enqueued").
>
> Could you resend this as a two-patch series: this patch plus a 5.15.y
> adaptation of 40a25d59e85b3c? Also worth considering as a third patch is
> 74e144274af399 ("futex/requeue: Prevent NULL pointer dereference in
> remove_waiter() on self-deadlock").

For completeness, we also reviewed the related patches yesterday.

Our understanding is that the correct backport set is this patch plus
40a25d59e85b3c. This patch fixes the original issue, while
40a25d59e85b3c fixes the NULL-pointer dereference. We also noticed
that 40a25d59e85b3c appears to cover a separate
use-before-initialization case, although that case is not relevant to
this backport.

I do not think 74e144274af399 should be included. It was later
reverted by 39def6d250d3, and the revert changelog says that the issue
was already handled by 40a25d59e85b3c. It also notes that
74e144274af399 introduced new problems.

>
> --
> Thanks,
> Sasha

Re: [PATCH 5.15.y] rtmutex: Use waiter::task instead of current in remove_waiter()

[Thomas Gleixner]

On Wed, Jul 08 2026 at 18:53, Wu Frank wrote:
> On Wed, Jul 8, 2026 at 6:04 PM Sasha Levin <sashal@kernel.org> wrote:
>> Could you resend this as a two-patch series: this patch plus a 5.15.y
>> adaptation of 40a25d59e85b3c? Also worth considering as a third patch is
>> 74e144274af399 ("futex/requeue: Prevent NULL pointer dereference in
>> remove_waiter() on self-deadlock").
>
> For completeness, we also reviewed the related patches yesterday.
>
> Our understanding is that the correct backport set is this patch plus
> 40a25d59e85b3c. This patch fixes the original issue, while
> 40a25d59e85b3c fixes the NULL-pointer dereference. We also noticed
> that 40a25d59e85b3c appears to cover a separate
> use-before-initialization case, although that case is not relevant to
> this backport.
>
> I do not think 74e144274af399 should be included. It was later
> reverted by 39def6d250d3, and the revert changelog says that the issue
> was already handled by 40a25d59e85b3c. It also notes that
> 74e144274af399 introduced new problems.

Only 40a25d59e85b3c needs to be backported. 74e144274af399 is not
required and buggy and got reverted upstream.

Thanks,

        tglx