[rlc-10/6.12.0-211.30.1.el10_2] rtmutex remove_waiter() fixes (2 commits)

[kerneltoast]

Summary

Opened by hand and trimmed to GhostLock-only. This base (rlc-10/6.12.0-211.30.1.el10_2) doesn't carry the KernelCI trigger workflow yet, so the automation can't build these commits or open the PR on its own. Same setup as the rlc-9 PR #1431.

The rlc-10 backport started out as epoll + GhostLock, but the coming 211.32.1 base already carries the whole epoll fix chain (the rocky10_2 rebuild #1430 backports "fix ep_remove ... UAF", "defer struct eventpoll free to RCU grace period", "move epi_fget() up", "annotate racy check", plus "fs: port files to file_ref"). So the epoll commits are dropped here, mirroring rlc-9: only the GhostLock pair (CVE-2026-43499 and its follow-up CVE-2026-53163) stays, sitting on the current 211.30.1 base, to be rebased onto 211.32.1 once that base lands. That base still lacks GhostLock (its remove_waiter() uses current, not waiter->task), so the pair is genuinely needed.

The two commits touch just kernel/locking/rtmutex.c and kernel/locking/rtmutex_api.c, no epoll here by design. Neither carries an upstream-diff block since the 6.12 code matches upstream.

Heads-up for the rebase: 211.32.1 reworks rtmutex (e.g., "Handle non enqueued waiters gracefully in remove_waiter()", "Simplify remove_waiter()", "Restructure rt_mutex_finish_proxy_lock()"), so this patch may need context adaptation when it's replayed there.

Commit Message(s)

rtmutex: Use waiter::task instead of current in remove_waiter()

cve CVE-2026-43499
commit-author Keenan Dong <keenanat2000@gmail.com>
commit 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349

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

(cherry picked from commit 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349)
Signed-off-by: Sultan Alsawaf <sultan@ciq.com>

locking/rtmutex: Skip remove_waiter() when waiter is not enqueued

cve CVE-2026-53163
commit-author Davidlohr Bueso <dave@stgolabs.net>
commit 40a25d59e85b3c8709ac2424d44f65610467871e

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().

Fixes: 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()")
Reported-by: syzbot+78147abe6c524f183ee9@syzkaller.appspotmail.com
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/69f114ac.050a0220.ac8b.0003.GAE@google.com/
Link: https://patch.msgid.link/20260507112913.1019537-1-dave@stgolabs.net

(cherry picked from commit 40a25d59e85b3c8709ac2424d44f65610467871e)
Signed-off-by: Sultan Alsawaf <sultan@ciq.com>

Test Results

Not run yet. This base carries only the reusable build-check_*.yml, not kernel-build-and-test-multiarch-trigger.yml, so nothing fires on push. The build, boot, kselftest, and LTP stages run once these commits are rebased onto 211.32.1 (which has the KernelCI install).