CVE-2026-53163

What it actually does

This is a Linux kernel flaw in the real-time mutex and futex handling path, specifically around FUTEX_CMP_REQUEUE_PI and rtmutex waiter cleanup. Under a particular deadlock or proxy-locking sequence, the kernel may call remove_waiter() for a waiter that was never fully enqueued and whose task pointer is NULL, causing a kernel NULL pointer dereference. The practical technical result is a local denial of service: an unprivileged or low-privileged local process may be able to trigger a kernel crash, panic, or system instability if the vulnerable kernel configuration and code path are reachable.

Why it matters to the business

Successful exploitation can cause affected Linux systems to crash or become unstable, interrupting workloads, services, containers, virtual machines, or appliances that rely on the vulnerable kernel. Because the issue is local and currently has low EPSS, no known KEV listing, no known ransomware association, and no public exploit maturity indicated, broad internet-driven exploitation is less likely; however, multi-user systems, shared hosting, container platforms, build runners, and environments that allow untrusted local code execution have higher operational risk.

How an attack unfolds

An attacker first needs the ability to execute code locally on a vulnerable Linux system, such as through a shell account, compromised application user, malicious workload, container escape-adjacent scenario, CI job, or other code execution foothold. The attacker then invokes futex operations that exercise the priority-inheritance requeue path, particularly FUTEX_CMP_REQUEUE_PI, and manipulates timing and lock state so the rtmutex code reaches a deadlock or proxy-lock condition where the waiter is not actually enqueued. In the vulnerable kernel path, cleanup incorrectly attempts to remove that non-enqueued waiter, dereferencing a NULL task pointer. This causes a kernel fault that can crash the host or trigger a panic depending on kernel configuration, watchdog behavior, and distribution defaults. The flaw is not described as enabling privilege escalation or remote code execution; the expected impact is availability loss.

How to fix it

Apply a kernel update that includes the upstream fix for the rtmutex/futex waiter handling issue, specifically the change that skips remove_waiter() when the waiter is not enqueued and tightens rt_mutex_start_proxy_lock() return handling. Use the fixed kernel packages provided by the relevant Linux distribution, appliance vendor, cloud image provider, or device manufacturer. If a fixed kernel is not yet available, reduce exposure by limiting local shell access, restricting execution of untrusted workloads, isolating tenants and containers on separate hosts where possible, applying seccomp/AppArmor/SELinux profiles that restrict futex-related attack surface when compatible with workloads, and prioritizing patching for shared compute, container hosts, CI/CD runners, VDI, HPC, and other systems where untrusted users can run code. A reboot is typically required after installing a kernel update to load the fixed kernel.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, after remediation. Verify that the active kernel includes the vendor fix for CVE-2026-53163 or the corresponding upstream Linux patch for locking/rtmutex waiter handling. On package-managed systems, validate with the distribution’s advisory tooling and ensure the host has rebooted into the patched kernel. Review crash history and kernel logs for prior NULL pointer dereferences involving remove_waiter(), rt_mutex_start_proxy_lock(), futex_requeue(), or FUTEX_CMP_REQUEUE_PI. Where feasible, run vendor-approved regression or kernel self-tests for futex and priority-inheritance locking; avoid running untrusted proof-of-concept code on production systems.

Typical attack path

1. Gain local code execution on a Linux system running a vulnerable kernel.
2. Create one or more threads or processes that use futex priority-inheritance behavior.
3. Trigger the FUTEX_CMP_REQUEUE_PI path with carefully arranged locking, requeue, and deadlock conditions.
4. Force the kernel into rt_mutex_start_proxy_lock() cleanup behavior where remove_waiter() is called on a waiter that was not enqueued.
5. Cause a NULL pointer dereference in kernel rtmutex handling, leading to kernel oops, panic, reboot, or service disruption.

How to detect it

Look for evidence of kernel crashes, oops reports, panics, or abnormal reboots associated with the rtmutex and futex code paths. Relevant log sources include kernel ring buffer output, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore artifacts, hypervisor reset events, endpoint telemetry, and uptime/reboot records. Search for stack traces containing remove_waiter(), rt_mutex_start_proxy_lock(), futex_requeue(), __x64_sys_futex(), FUTEX_CMP_REQUEUE_PI, or KASAN NULL pointer dereference messages near the time of an unexpected outage. Because this is a kernel denial-of-service issue, exploitation may leave little application-layer evidence; correlation should focus on local process execution immediately before a crash, repeated crashes by the same user or workload, suspicious stress-test binaries, fuzzing tools, or newly introduced untrusted jobs. No named threat actors or public exploitation campaigns are currently indicated in the provided data.

• KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f]
• 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
• FUTEX_CMP_REQUEUE_PI
• kernel/locking/rtmutex.c
• task_blocks_on_rt_mutex
• remove_waiter()
• rt_mutex_start_proxy_lock()
• futex_requeue()
• KASAN: null-ptr-deref

What your security team should do

• Inventory Linux systems and identify those running kernels that do not include the rtmutex/futex fix.
• Prioritize patching systems where untrusted or semi-trusted users can execute local code, including container hosts, shared compute platforms, CI runners, developer workstations, and multi-user servers.
• Install vendor-provided fixed kernel packages and reboot systems to ensure the patched kernel is active.
• Monitor kernel logs, crash dumps, and system availability telemetry for signs of futex-triggered kernel oops or panic activity.
• Temporarily restrict local access and untrusted workload execution on high-value or shared systems until patched.
• Ensure crash dump collection such as kdump, journald persistent logging, or centralized syslog is enabled so suspected exploitation can be investigated.
• Track distribution and appliance vendor advisories because fixed package names and versions vary by kernel branch and backport policy.