FAILED: patch "[PATCH] futex/requeue: Prevent NULL pointer dereference in" failed to apply to 5.15-stable tree
Subsystems (2)
[email protected]
maintainerThe 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 <[email protected]>.
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 74e144274af39935b0f410c0ee4d2b91c3730414
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026072141-ravage-display-0696@gregkh' --subject-prefix 'PATCH 5.15.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 74e144274af39935b0f410c0ee4d2b91c3730414 Mon Sep 17 00:00:00 2001
From: Ji'an Zhou <[email protected]>
Date: Tue, 2 Jun 2026 09:12:04 +0000
Subject: [PATCH] futex/requeue: Prevent NULL pointer dereference in
remove_waiter() on self-deadlock
When FUTEX_CMP_REQUEUE_PI requeues a non-top waiter that already owns the target PI futex, task_blocks_on_rt_mutex() returns -EDEADLK before setting waiter->task.
The subsequent remove_waiter() in rt_mutex_start_proxy_lock() dereferences the NULL waiter->task, causing a kernel crash.
Add a self-deadlock check for non-top waiters before calling rt_mutex_start_proxy_lock(), analogous to the top-waiter check in futex_lock_pi_atomic().
kernel/futex/requeue.c +6 -0
@@ -643,6 +643,12 @@ int futex_requeue(u32 __user *uaddr1, unsigned int flags1,continue ; } +/* Self-deadlock: non-top waiter already owns the PI futex. */ +if (rt_mutex_owner (&pi_state->pi_mutex) == this->task) { + ret = -EDEADLK ; +break ; + } + ret =rt_mutex_start_proxy_lock (&pi_state->pi_mutex, this->rt_waiter, this->task);
Thomas Gleixner
maintainercover rtmutex/futex: Backport of rejecting fixes
As promised the backports of:
3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") 40a25d59e85b ("locking/rtmutex: Skip remove_waiter() when waiter is not enqueued")
for 5.15.y.
Thanks,
tglx
Thomas Gleixner
maintainerPATCH 1/2 rtmutex: Use waiter::task instead of current in remove_waiter()
From: Keenan Dong <[email protected]>
commit 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 upstream.
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 ]
[ tglx: Backport for 5.10.y and 5.15.y. The commit has not been backported
yet because the Fixes tag is wrong. Fixes: points now to the real culprit. ]
--- kernel/locking/rtmutex.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
---
kernel/locking/rtmutex.c +7 -4
@@ -1500,20 +1500,23 @@ static bool rtmutex_spin_on_owner(struct* * 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 (¤t->pi_lock); +raw_spin_lock (&waiter_task->pi_lock);rt_mutex_dequeue (lock, waiter); - current->pi_blocked_on =NULL ; -raw_spin_unlock (¤t->pi_lock); + waiter_task->pi_blocked_on =NULL ; +raw_spin_lock (&waiter_task->pi_lock);/* * Only update priority if the waiter was the highest priority
@@ -1549,7 +1552,7 @@ static void __sched remove_waiter(structraw_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); }
Thomas Gleixner
maintainerPATCH 2/2 locking/rtmutex: Skip remove_waiter() when waiter is not enqueued
In reply to Thomas GleixnerFrom: Davidlohr Bueso <[email protected]>
commit 40a25d59e85b3c8709ac2424d44f65610467871e upstream.
syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI:
KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0
task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal.
Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().
--- kernel/locking/rtmutex.c | 3 +++ kernel/locking/rtmutex_api.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)
---
kernel/locking/rtmutex.c +3 -0
@@ -1513,6 +1513,9 @@ static void __sched remove_waiter(structlockdep_assert_held (&lock->wait_lock); +if (!waiter_task)/* never enqueued */ +return ; +raw_spin_lock (&waiter_task->pi_lock);rt_mutex_dequeue (lock, waiter); waiter_task->pi_blocked_on =NULL ;
kernel/locking/rtmutex_api.c +1 -1
@@ -322,7 +322,7 @@ int __sched rt_mutex_start_proxy_lock(straw_spin_lock_irq (&lock->wait_lock); ret =__rt_mutex_start_proxy_lock (lock, waiter, task); -if (unlikely (ret)) +if (unlikely (ret <0 ))remove_waiter (lock, waiter);raw_spin_unlock_irq (&lock->wait_lock);