CVE-2026-31555

What it actually does

This is a local Linux kernel race condition in the priority-inheritance futex path, specifically in futex_lock_pi(). When a thread encounters an exiting futex owner, the kernel stores a referenced task pointer, waits for the owner-exit path, releases the reference, and retries. On the retry path, the pointer was not cleared. If the next futex operation returns a different error, the stale pointer can be passed back into wait_for_owner_exiting(), triggering a kernel WARN condition. The direct impact is availability: an unprivileged local user that can exercise PI futex operations may be able to trigger repeated kernel warnings and, on systems configured to panic on warnings or with related hardening/debug settings, cause a system crash or service disruption. The vulnerability does not provide direct confidentiality or integrity impact based on the published description.

Why it matters to the business

The primary business risk is local denial of service on Linux systems. A user or compromised low-privilege process on a vulnerable host may be able to destabilize workloads, crash systems configured to panic on kernel warnings, or create operational noise through repeated kernel warnings. This is especially relevant for multi-user systems, shared compute platforms, container hosts, CI/build infrastructure, and any environment where untrusted or semi-trusted code can run locally. Public exploitation maturity is currently reported as none, EPSS is very low and stable, and it is not listed in CISA KEV, so urgency is lower than actively exploited remote vulnerabilities; however, kernel availability flaws should still be addressed through normal patch cycles, especially on shared or high-availability systems.

How an attack unfolds

An attacker needs local code execution with the ability to invoke futex operations. They run a program that stresses priority-inheritance futex locking while racing one thread or process exiting against another thread attempting futex_lock_pi() on the same futex address. In the vulnerable retry sequence, futex_lock_pi_atomic() first observes the futex owner in EXITING state, stores a referenced task pointer, and returns -EBUSY. wait_for_owner_exiting() consumes and releases that reference, but the local pointer remains non-null. The attacker then causes the retry to take a different path, such as returning -EAGAIN after the futex value changes. The stale pointer is incorrectly supplied to wait_for_owner_exiting(), causing the kernel to hit a WARN_ON_ONCE condition. Repeated triggering may degrade system reliability and, where kernel.panic_on_warn is enabled, convert the warning into a kernel panic and host outage.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the futex fix to clear the stale exiting pointer in the futex_lock_pi() retry path. No exact fixed package versions were provided in the input, so use the vendor advisory for the relevant distribution, appliance, cloud image, or embedded kernel branch to identify the corrected kernel build. After installing the fixed kernel, reboot into it; kernel updates are not effective while the vulnerable kernel remains running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting execution of untrusted code, hardening container and sandbox boundaries, and reviewing whether kernel.panic_on_warn is enabled on systems where availability is more important than immediate crash-on-warning behavior. These mitigations reduce exploitability or blast radius but do not replace the kernel fix.

How to confirm the fix worked

Confirm the running kernel version is the vendor-fixed build, not merely that a patched package is installed. On Linux systems, compare uname -a or /proc/version against the vendor advisory and package manager metadata. Verify the host has been rebooted after the kernel update. Review bootloader defaults to ensure the patched kernel is the active default. For high-assurance validation, run vendor-provided regression tests or controlled futex stress tests on non-production systems and confirm the prior WARNING in kernel/futex/core.c no longer occurs. Also check system settings such as kernel.panic_on_warn to understand whether similar kernel warnings would cause immediate outages.

Typical attack path

1. Obtain local execution on a vulnerable Linux system as a low-privileged user or through a compromised application/container with access to futex syscalls.
2. Create shared memory containing a priority-inheritance futex word used by multiple threads or processes.
3. Have one thread or process acquire the PI futex and begin exiting so the kernel marks the futex owner as EXITING during futex cleanup.
4. Race another thread or process into futex_lock_pi() so futex_lock_pi_atomic() observes the exiting owner and returns -EBUSY with an owner task reference.
5. Allow wait_for_owner_exiting() to consume the reference, then force the retry path to encounter a different condition such as -EAGAIN after the futex value changes.
6. Trigger the stale exiting pointer path and kernel WARN condition.
7. Repeat the race to create log noise, reliability degradation, or a system panic where panic-on-warn behavior is enabled.

How to detect it

Look for evidence of local futex stress or repeated kernel warnings rather than remote network indicators. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kernel panic records, auditd exec logs, EDR process telemetry, and container runtime logs showing unusual local programs that create many threads or make heavy futex syscalls. Search for WARN messages referencing kernel/futex/core.c, wait_for_owner_exiting, futex_lock_pi, futex_lock_pi_s, or WARN_ON_ONCE(exiting). Correlate any such warnings with local process execution around the same timestamp, especially newly introduced test binaries, stress tools, fuzzers, or short-lived multi-threaded processes. If the system crashed, inspect kdump/vmcore, pstore, ramoops, systemd journal from the previous boot, and hypervisor reset events for kernel panic or BUG/WARNING output containing futex symbols. There are no meaningful network IOCs because exploitation is local.

• WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting
• wait_for_owner_exiting+0x7a/0x80
• futex_lock_pi_s
• futex_lock_pi
• futex_lock_pi_atomic
• WARN_ON_ONCE(exiting)
• kernel/futex/core.c
• CPU#11: futex_lock_pi_s
• panic_on_warn
• Kernel panic - not syncing: panic_on_warn set

What your security team should do

• Prioritize patching shared, multi-user, container-hosting, CI/build, HPC, desktop, and workload-consolidation Linux systems where untrusted or low-privilege code can execute locally.
• Track the relevant Linux distribution or appliance vendor advisory and deploy the kernel build that contains the futex_lock_pi() stale exiting pointer fix.
• Reboot systems after patch installation and verify the fixed kernel is actually running.
• Search historical kernel logs for futex-related WARN messages to identify possible prior triggering or stability events.
• Review kernel.panic_on_warn settings on critical availability systems and ensure the setting reflects the organization’s operational risk tolerance.
• Limit local code execution pathways where patching is delayed, including unnecessary shell access, untrusted job execution, and weak container isolation.
• Because EPSS is low, exploit maturity is reported as none, and there is no KEV listing, handle through the standard kernel vulnerability maintenance process unless the environment permits untrusted local code execution at scale.