CVE-2026-53166

What it actually does

This is a Linux kernel denial-of-service flaw in the futex priority-inheritance requeue path. A specially constructed FUTEX_CMP_REQUEUE_PI operation can trigger a self-deadlock condition where a non-top waiter already owns the target priority-inheritance futex. In that edge case, task_blocks_on_rt_mutex() returns an error before initializing waiter->task, and the later remove_waiter() path dereferences that NULL task pointer. The result is a kernel NULL pointer dereference, typically causing an oops, panic, or system crash depending on kernel panic settings.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, containers, virtual machines, appliances, or services that depend on the host kernel. The issue is not known to be remotely exploitable by itself, is not listed in CISA KEV, has no reported ransomware association, and currently has a very low EPSS score, so broad internet-scale exploitation is unlikely. However, because futex operations are available to local user-space programs, shared systems, container hosts, CI runners, developer workstations, and multi-tenant Linux platforms should treat this as a local availability risk.

How an attack unfolds

An attacker first needs the ability to execute code locally on an affected Linux system, such as through a shell account, compromised service account, container escape-adjacent position where host kernel syscalls are reachable, or execution inside a workload that can invoke futex syscalls. The attacker then creates multiple threads and futex waiters arranged so that a FUTEX_CMP_REQUEUE_PI operation attempts to requeue a non-top waiter onto a priority-inheritance futex already owned by that same waiter. This triggers the self-deadlock path: task_blocks_on_rt_mutex() detects the deadlock and returns -EDEADLK before waiter->task is set. The kernel cleanup path then calls remove_waiter(), which assumes waiter->task is valid and dereferences a NULL pointer. The likely outcome is a kernel oops or panic, causing denial of service. There is no current public indication from the supplied data that this vulnerability is being exploited in the wild or used by named threat actors.

How to fix it

Apply a kernel update from the relevant Linux distribution or kernel vendor that includes the futex/requeue fix adding a self-deadlock check before rt_mutex_start_proxy_lock() for non-top waiters. Because no affected product list or fixed package versions were provided, use vendor advisories, distribution security trackers, and kernel changelogs to identify the first fixed kernel for each supported platform. After installing the update, reboot into the patched kernel; merely installing kernel packages is insufficient if the system continues running an older kernel. Where immediate patching is not possible, reduce exposure by limiting untrusted local code execution, tightening access to shared shell or build systems, isolating untrusted workloads on dedicated hosts, applying container security controls, and monitoring for kernel crashes involving futex, rt_mutex, or remove_waiter paths.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is patched. On Linux systems, compare `uname -r` and package manager output against the distribution's fixed kernel advisory. Validate that hosts have rebooted into the updated kernel after patch installation. Review kernel changelogs or vendor backport notes for the futex/requeue self-deadlock fix, since enterprise distributions may backport the patch without changing to an upstream version number that obviously appears fixed. For exposure checks, identify systems that allow untrusted local execution or run multi-tenant workloads; those systems have the highest practical risk. Avoid validating with untrusted crash-triggering proof-of-concept code on production systems because exploitation intentionally risks kernel panic.

Typical attack path

1. Gain local code execution on an affected Linux system, container, or workload that can invoke futex syscalls against the host kernel.
2. Create a multithreaded program that sets up priority-inheritance futexes and multiple waiters.
3. Arrange the waiter state so a non-top waiter already owns the target PI futex.
4. Invoke FUTEX_CMP_REQUEUE_PI to requeue that waiter onto the target futex.
5. Trigger the self-deadlock handling path where waiter->task remains NULL.
6. Cause remove_waiter() to dereference the NULL waiter->task pointer.
7. Crash or destabilize the kernel, producing a denial-of-service condition.

How to detect it

Look for evidence of prior kernel crashes rather than conventional malware indicators. Relevant sources include systemd journal, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump directories, kdump/vmcore storage, pstore records, hypervisor reset events, and endpoint telemetry that captures kernel panics. Search for kernel oops or panic messages with stack frames referencing futex requeue, priority-inheritance futexes, rt_mutex_start_proxy_lock(), remove_waiter(), or task_blocks_on_rt_mutex(). If auditd, eBPF, or syscall tracing was enabled before the event, look for a local process repeatedly invoking the futex syscall with FUTEX_CMP_REQUEUE_PI shortly before the crash. Correlate crash timestamps with recently started local processes, container workloads, CI jobs, or user sessions. Absence of these artifacts does not prove non-exploitation because a successful denial-of-service may prevent logs from flushing to disk.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• remove_waiter
• rt_mutex_start_proxy_lock
• task_blocks_on_rt_mutex
• futex_requeue
• FUTEX_CMP_REQUEUE_PI
• futex/requeue
• /sys/fs/pstore/
• /var/crash/
• /var/lib/systemd/coredump/
• /proc/vmcore

What your security team should do

• Prioritize patching Linux systems that run untrusted local code, shared development workloads, CI/CD runners, container platforms, hosting environments, or multi-tenant services.
• Track vendor-specific kernel advisories and deploy the first fixed kernel available for each distribution; reboot systems after installation.
• Inventory running kernel versions and flag hosts where the installed fixed kernel is not the active booted kernel.
• Review recent kernel crash, oops, panic, pstore, and vmcore records for stack traces involving futex requeue, rt_mutex_start_proxy_lock(), remove_waiter(), or task_blocks_on_rt_mutex().
• Restrict local access for untrusted users and workloads until patching is complete.
• For containerized environments, remember that containers share the host kernel; patch the host kernel, not only container images.
• Because this issue is not KEV-listed, has no ransomware association, no known mature exploit, and low EPSS, handle it through normal kernel patch governance unless the environment has high local multi-tenant exposure.