Bug 2492805 (CVE-2026-53166)

Summary: CVE-2026-53166 kernel: futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: kevinxue, rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's futex (Fast Userspace Mutex) requeue mechanism. When a non-top waiter attempts to requeue a Priority Inheritance (PI) futex it already owns, a NULL pointer dereference can occur. This issue, specifically within the `remove_waiter()` function during a self-deadlock scenario, leads to a kernel crash, resulting in a Denial of Service (DoS).
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-06-25 10:06:42 UTC 
In the Linux kernel, the following vulnerability has been resolved:

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().
Comment 1 TEJ RATHI 2026-06-26 07:10:56 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026062551-CVE-2026-53166-2861@gregkh/T
Comment 5 errata-xmlrpc 2026-07-10 12:24:27 UTC 
This issue has been addressed in the following products:

  NVIDIA for RHEL 10

Via RHSA-2026:37728 https://access.redhat.com/errata/RHSA-2026:37728