Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-53163

CVE-2026-53163: Linux Kernel Race Condition Vulnerability

CVE-2026-53163 is a race condition flaw in the Linux kernel's rtmutex locking mechanism that causes null pointer dereference errors. This article covers the technical details, affected versions, and mitigation strategies.

Published:

CVE-2026-53163 Overview

CVE-2026-53163 is a Linux kernel vulnerability in the realtime mutex (rtmutex) locking subsystem. The flaw resides in remove_waiter() within kernel/locking/rtmutex.c and is reachable through the FUTEX_CMP_REQUEUE_PI operation of the futex syscall. syzbot fuzzing exposed a KASAN null-pointer dereference triggered when task_blocks_on_rt_mutex() detects a deadlock and returns without arming the waiter, leaving waiter->task set to nil. A subsequent call to remove_waiter() then dereferences the unarmed waiter, producing a kernel oops.

Critical Impact

Local unprivileged users can trigger a null-pointer dereference in the kernel locking subsystem via the futex syscall, resulting in a kernel crash and denial of service.

Affected Products

  • Linux kernel versions containing commit 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()")
  • Linux kernel branches incorporating commit 1a1fb985f2e2 ("futex: Handle early deadlock return correctly")
  • Mainline and stable kernel trees prior to the fix commits referenced in the kernel.org changelog

Discovery Timeline

  • 2026-06-25 - CVE-2026-53163 published to NVD
  • 2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53163

Vulnerability Analysis

The vulnerability is a null-pointer dereference [CWE-476] in the kernel rtmutex priority-inheritance locking code. syzbot reported the following KASAN splat:

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

The crash path begins in __x64_sys_futex handling a FUTEX_CMP_REQUEUE_PI request. futex_requeue() invokes rt_mutex_start_proxy_lock(), which then enters remove_waiter() on an rtmutex waiter that was never enqueued. The class constructor for the waiter's raw spinlock dereferences a null waiter->task, producing the oops.

Root Cause

Two prior changes interact unsafely. Commit 3bfdc63936dd changed remove_waiter() to use waiter::task rather than current, assuming the waiter is always armed. Commit 1a1fb985f2e2 then moved the remove_waiter() call from inside __rt_mutex_start_proxy_lock() out into the wrapper. However, task_blocks_on_rt_mutex() skips arming the waiter when it detects an early deadlock, and the wrapper also invokes remove_waiter() after a successful try_to_take_rt_mutex(). In both cases the waiter is not enqueued, and remove_waiter() operates on uninitialized waiter state.

Attack Vector

The issue is locally reachable through the futex(2) syscall using FUTEX_CMP_REQUEUE_PI. An unprivileged local user can craft contending futex operations to drive the rtmutex code into the deadlock-detection or fast-acquisition path and trigger the dereference. Successful exploitation crashes the kernel and denies service to all users on the host. Remote exploitation is not applicable.

Detection Methods for CVE-2026-53163

Indicators of Compromise

  • Kernel oops or panic messages referencing remove_waiter+, rt_mutex_start_proxy_lock, or futex_requeue in dmesg or /var/log/kern.log.
  • KASAN reports of the form null-ptr-deref in range [0x0...0a88-0x0...0a8f] from kernel/locking/rtmutex.c.
  • Unexpected host reboots or hangs correlated with workloads using PI futexes.

Detection Strategies

  • Compare running kernel build identifiers against the fixed commits 40a25d59e85b, 55363fa0a045, and a388e3dfaf95 published on kernel.org.
  • Run kernel self-tests and futex stress tools (for example perf bench futex and futextest) under KASAN-enabled debug kernels to surface the splat.
  • Monitor crash-dump collectors (kdump, systemd-coredump) for new entries pointing into kernel/locking/rtmutex.c.

Monitoring Recommendations

  • Forward dmesg and journal kernel facility logs to a central log store and alert on BUG:, KASAN, or Oops: entries naming rtmutex or futex symbols.
  • Track futex syscall volume per process; sustained FUTEX_CMP_REQUEUE_PI calls from unprivileged accounts warrant investigation.
  • Watch host availability and kernel-panic counters in fleet monitoring to identify clusters of crashes consistent with this bug.

How to Mitigate CVE-2026-53163

Immediate Actions Required

  • Apply the upstream fix commits referenced in the kernel.org changelog and rebuild or update the kernel package.
  • Reboot affected hosts onto the patched kernel; the rtmutex code path cannot be hot-patched safely without a kernel update.
  • Restrict execution of untrusted local code on multi-tenant systems until patching is complete.

Patch Information

The fix tightens the return-value check in rt_mutex_start_proxy_lock() so that remove_waiter() is only called when the waiter was actually enqueued, accounting for both deadlock-detection and try_to_take_rt_mutex() success paths. Refer to Kernel Commit 40a25d5 Fix, Kernel Commit 55363fa0 Update, and Kernel Commit a388e3df Change for the stable-tree backports.

Workarounds

  • No supported configuration workaround removes the code path; FUTEX_CMP_REQUEUE_PI is required by glibc PI mutex implementations.
  • On multi-tenant hosts, reduce exposure by limiting untrusted local users and containerized workloads with seccomp profiles that deny futex PI operations where feasible.
  • Enable kernel.panic_on_oops=0 is not recommended; instead enable kdump to capture diagnostics if a crash occurs before patching completes.
bash
# Verify the running kernel and confirm the patch is present
uname -r
zgrep -E 'rtmutex|remove_waiter' /proc/kallsyms | head
# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r | sed 's/.*-//')
# RHEL/Rocky/Alma
sudo dnf update kernel && sudo reboot

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.