Skip to content

[rlc-8/4.18.0-553.139.1.el8_10] Multiple patches tested (2 commits)#1427

Open
ciq-kernel-automation[bot] wants to merge 2 commits into
rlc-8/4.18.0-553.139.1.el8_10from
{sultan_futex}_rlc-8/4.18.0-553.139.1.el8_10
Open

[rlc-8/4.18.0-553.139.1.el8_10] Multiple patches tested (2 commits)#1427
ciq-kernel-automation[bot] wants to merge 2 commits into
rlc-8/4.18.0-553.139.1.el8_10from
{sultan_futex}_rlc-8/4.18.0-553.139.1.el8_10

Conversation

@ciq-kernel-automation

Copy link
Copy Markdown

Summary

This PR has been automatically created after successful completion of all CI stages.

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
upstream-diff |
        This tree builds with -std=gnu89, which rejects upstream's
        scoped_guard() form (cleanup.h expands it to a for-loop that
        declares a variable in the initializer), so an explicit
        raw_spin_lock()/raw_spin_unlock() pair on waiter_task->pi_lock is
        used instead. The locking is identical; the comment, the
        waiter_task local, and the rt_mutex_adjust_prio_chain() argument
        match upstream.
locking/rtmutex: Skip remove_waiter() when waiter is not enqueued

cve CVE-2026-53163
commit-author Davidlohr Bueso <dave@stgolabs.net>
commit 40a25d59e85b3c8709ac2424d44f65610467871e
upstream-diff |
        Functionally identical. In rtmutex_api.c the remove_waiter() call
        is gated on ret < 0 (skipped on the ret == 1 acquired path); this
        tree's __rt_mutex_start_proxy_lock() has no @wake_q and no
        preempt_disable() around the wait_lock release (later reworks), so
        only the context was adjusted. In rtmutex.c the !waiter_task guard
        is verbatim, atop the explicit-lock form from the previous commit.

Test Results

✅ Build Stage

Architecture Build Time Total Time
x86_64 24m 8s 25m 7s
aarch64 10m 31s 11m 14s

✅ Boot Verification

✅ Kernel Selftests

Architecture Passed Failed Compared Against Status
x86_64 120 36 rlc-8/4.18.0-553.139.1.el8_10 ✅ No regressions
aarch64 72 32 rlc-8/4.18.0-553.139.1.el8_10 ✅ No regressions

✅ LTP Results

Architecture Passed Failed Compared Against Status
x86_64 1408 84 rlc-8/4.18.0-553.139.1.el8_10 ❌ 1 regressions
aarch64 1381 83 rlc-8/4.18.0-553.139.1.el8_10 ✅ No regressions

x86_64 regressions:

  • futex_wake02 (PASS -> FAIL)

🤖 This PR was automatically generated by GitHub Actions
Run ID: 29075373448

Niebelungen-D and others added 2 commits July 9, 2026 19:49
cve CVE-2026-43499
commit-author Keenan Dong <keenanat2000@gmail.com>
commit 3bfdc63
upstream-diff |
        This tree builds with -std=gnu89, which rejects upstream's
        scoped_guard() form (cleanup.h expands it to a for-loop that
        declares a variable in the initializer), so an explicit
        raw_spin_lock()/raw_spin_unlock() pair on waiter_task->pi_lock is
        used instead. The locking is identical; the comment, the
        waiter_task local, and the rt_mutex_adjust_prio_chain() argument
        match 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 ]

Fixes: 8161239 ("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 3bfdc63)
	Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
cve CVE-2026-53163
commit-author Davidlohr Bueso <dave@stgolabs.net>
commit 40a25d5
upstream-diff |
        Functionally identical. In rtmutex_api.c the remove_waiter() call
        is gated on ret < 0 (skipped on the ret == 1 acquired path); this
        tree's __rt_mutex_start_proxy_lock() has no @wake_q and no
        preempt_disable() around the wait_lock release (later reworks), so
        only the context was adjusted. In rtmutex.c the !waiter_task guard
        is verbatim, atop the explicit-lock form from the previous commit.

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 3bfdc63 ("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. 1a1fb98 ("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: 3bfdc63 ("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 40a25d5)
	Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
@ciq-kernel-automation ciq-kernel-automation Bot added the created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI) label Jul 10, 2026
@github-actions

Copy link
Copy Markdown

🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/29087159747

@github-actions

Copy link
Copy Markdown

🔍 Upstream Linux Kernel Commit Check

  • ⚠️ PR commit 653186d8bee3 (rtmutex: Use waiter::task instead of current in remove_waiter()) references upstream commit
    3bfdc63936dd which has been referenced by a Fixes: tag in the upstream
    Linux kernel:
    74e144274af3 futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock (Ji'an Zhou) (CVE-2026-53166)

This is an automated message from the kernel commit checker workflow.

@github-actions

Copy link
Copy Markdown

🔍 Interdiff Analysis

  • ⚠️ PR commit 653186d8bee3 (rtmutex: Use waiter::task instead of current in remove_waiter()) → upstream 3bfdc63936dd
    Differences found:
================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1514,10 +1514,10 @@
 
 	lockdep_assert_held(&lock->wait_lock);
 
-	raw_spin_lock(&waiter_task->pi_lock);
-	rt_mutex_dequeue(lock, waiter);
-	waiter_task->pi_blocked_on = NULL;
-	raw_spin_unlock(&waiter_task->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
  • ⚠️ PR commit 23804269a978 (locking/rtmutex: Skip remove_waiter() when waiter is not enqueued) → upstream 40a25d59e85b
    Differences found:
################################################################################
!    REJECTED PATCH2 HUNKS - could not be compared; manual review needed       !
################################################################################

--- b/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1558,6 +1558,9 @@
 
 	lockdep_assert_held(&lock->wait_lock);
 
+	if (!waiter_task) /* never enqueued */
+		return;
+
 	scoped_guard(raw_spinlock, &waiter_task->pi_lock) {
 		rt_mutex_dequeue(lock, waiter);
 		waiter_task->pi_blocked_on = NULL;
--- b/kernel/locking/rtmutex_api.c
+++ b/kernel/locking/rtmutex_api.c
@@ -365,7 +365,7 @@
 
 	raw_spin_lock_irq(&lock->wait_lock);
 	ret = __rt_mutex_start_proxy_lock(lock, waiter, task, &wake_q);
-	if (unlikely(ret))
+	if (unlikely(ret < 0))
 		remove_waiter(lock, waiter);
 	preempt_disable();
 	raw_spin_unlock_irq(&lock->wait_lock);

================================================================================
*    CONTEXT DIFFERENCES - surrounding code differences between the patches    *
================================================================================

--- b/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1511,6 +1511,6 @@
 
 	lockdep_assert_held(&lock->wait_lock);
 
-	raw_spin_lock(&waiter_task->pi_lock);
-	rt_mutex_dequeue(lock, waiter);
-	waiter_task->pi_blocked_on = NULL;
+	scoped_guard(raw_spinlock, &waiter_task->pi_lock) {
+		rt_mutex_dequeue(lock, waiter);
+		waiter_task->pi_blocked_on = NULL;
--- b/kernel/locking/rtmutex_api.c
+++ b/kernel/locking/rtmutex_api.c
@@ -320,5 +320,6 @@
 	raw_spin_lock_irq(&lock->wait_lock);
-	ret = __rt_mutex_start_proxy_lock(lock, waiter, task);
+	ret = __rt_mutex_start_proxy_lock(lock, waiter, task, &wake_q);
 	if (unlikely(ret))
 		remove_waiter(lock, waiter);
+	preempt_disable();
 	raw_spin_unlock_irq(&lock->wait_lock);

This is an automated interdiff check for backported commits.

@github-actions

Copy link
Copy Markdown

Validation checks completed successfully View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/29087159747

@bmastbergen bmastbergen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI)

Development

Successfully merging this pull request may close these issues.

3 participants