[rlc-9/5.14.0-687.22.1.el9_8] rtmutex remove_waiter() fixes (2 commits)

[kerneltoast]

Summary

Opened by hand: the rlc-9/5.14.0-687.22.1.el9_8 base doesn't carry the KernelCI trigger workflow yet, so the automation can't build these commits or open the PR itself. Per the discussion with Jonathan, this is the GhostLock pair (CVE-2026-43499 and its follow-up CVE-2026-53163) sitting on the current active rlc-9 base, to be rebased onto rlc-9/5.14.0-687.24.1.el9_8 (which already carries the epoll fixes) once the base-prep rebase lands.

GhostLock-only by design and knowingly epoll-less here: the two commits touch just kernel/locking/rtmutex.c and kernel/locking/rtmutex_api.c. This 5.14 el9_8 tree matches upstream verbatim, so unlike the el8 backports (#1427, #1429) neither commit needs an upstream-diff block.

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: Shreeya Patel <spatel@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: Shreeya Patel <spatel@ciq.com>

Test Results

Not run yet. This base carries only the reusable build-check_*.yml, not kernel-build-and-test-multiarch-trigger.yml, and nothing fires on push. The build, boot, kselftest, and LTP stages will run once the KernelCI install lands on the rlc-9 base, or when these commits are rebased onto 687.24.1.