CVE-2026-31554

What it actually does

This is a local Linux kernel use-after-free flaw in the futex requeue path. A process with local code execution can call the futex requeue interface with inconsistent flag combinations, causing the kernel to operate on futex state under assumptions that no longer hold. In practical terms, a successful exploit may corrupt kernel memory and can plausibly lead to local privilege escalation, kernel information disclosure, or a system crash. The CVSS vector indicates local access is required, attack complexity is low, no user interaction is required, and successful exploitation can impact confidentiality, integrity, and availability at the host level.

Why it matters to the business

The main business risk is that an attacker who already has a foothold on a Linux system, container host, developer workstation, appliance, or server may be able to escalate from a low-privileged account to full control of the machine. That can enable credential theft, tampering with workloads, disabling security controls, lateral movement, and service disruption. The issue is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS, and currently has no public exploit maturity reported, so urgency is lower than actively exploited kernel flaws; however, kernel privilege-escalation bugs should still be remediated through normal high-priority patch cycles, especially on multi-user systems, container platforms, shared compute, CI/CD runners, and internet-facing servers where an initial foothold is more likely.

How an attack unfolds

An attacker first needs the ability to run code locally on an affected Linux system, for example through a compromised user account, malicious workload, vulnerable service, container escape chain, or post-exploitation shell. They then invoke the affected futex requeue functionality with mismatched flags that the vulnerable kernel accepts. Because the vulnerable implementation allows inconsistent flag handling, internal futex objects can be freed while still being referenced. The attacker attempts to shape kernel heap memory so that the stale reference points to attacker-influenced data or otherwise corrupts useful kernel structures. A reliable exploit would use that corruption to elevate privileges, disable security controls, leak kernel memory, or crash the host. There is currently no known public exploit or named threat actor activity associated with this vulnerability, but similar local kernel memory-corruption flaws are commonly used after initial compromise to obtain root-level persistence and broader access.

How to fix it

Apply a Linux kernel update from the relevant operating system, appliance, cloud image, or distribution vendor that includes the upstream fix requiring sys_futex_requeue() calls to use identical flags. Because fixed version data was not provided, rely on vendor advisories and package changelogs for the exact patched kernel build. Reboot systems after installing the updated kernel and verify they are running the patched kernel, not merely that the package is installed. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, hardening container boundaries, using mandatory access control such as SELinux or AppArmor, keeping kernel lockdown and module-signing controls enabled where applicable, and prioritizing patching for shared hosts, container nodes, CI runners, bastion hosts, and systems where untrusted users or workloads can execute code. There is no general configuration-only mitigation that reliably removes the vulnerable kernel path without updating the kernel.

How to confirm the fix worked

Confirm remediation by checking the running kernel version against the patched kernel version listed by the Linux distribution or vendor advisory. Validate that the system has been rebooted into the fixed kernel using commands such as uname -a and the platform package manager's installed-kernel query. Review vendor changelogs or source package patches for references to the futex change requiring identical flags in sys_futex_requeue(). For exposure validation, inventory Linux systems and compare running kernel builds to vendor-fixed builds; pay special attention to container hosts and systems that may keep older kernels after package updates. Functional validation should be limited to vendor-provided regression or compliance checks; do not run untrusted proof-of-concept code on production systems.

Typical attack path

1. Gain local code execution on an affected Linux system as an unprivileged user or process.
2. Determine that the running kernel includes the vulnerable futex requeue implementation.
3. Run exploit code that calls the futex requeue interface with non-identical flag combinations.
4. Trigger a use-after-free condition in the kernel futex code path.
5. Manipulate kernel memory layout to turn the stale reference into controlled memory corruption.
6. Escalate privileges, leak sensitive kernel data, tamper with the host, or intentionally crash the system.

How to detect it

Detection is difficult because successful exploitation happens inside the kernel and may leave few stable artifacts. Start with host telemetry and audit logs for unusual local privilege-escalation patterns: unexpected processes becoming root, new setuid binaries, unauthorized changes to sudoers or privileged services, suspicious child processes spawned by low-privileged accounts, kernel oops or panic events, and abnormal crashes around futex handling. Review system logs such as journalctl, dmesg, /var/log/kern.log, /var/log/messages, auditd logs, EDR telemetry, process execution events, and container runtime logs. If syscall auditing or eBPF telemetry is available, look for unusual futex requeue activity from nonstandard programs, especially repeated requeue calls with varying flags followed by crashes or privilege changes. For containers, correlate suspicious activity in workloads with host-level kernel errors or unexpected privileged process creation. There are no known public exploit indicators, malware names, command lines, file paths, or threat actor tradecraft specific to this vulnerability, so detections should emphasize behavioral signs of local kernel exploitation rather than static IOCs.

• kernel BUG
• kernel oops
• Oops:
• general protection fault
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• futex
• sys_futex_requeue
• futex_requeue
• FUTEX_REQUEUE
• FUTEX_CMP_REQUEUE
• FUTEX_PRIVATE_FLAG
• FUTEX_CLOCK_REALTIME
• audit: type=SYSCALL
• syscall=futex

What your security team should do

• Inventory all Linux systems and identify those running affected kernel builds, including physical hosts, virtual machines, container nodes, CI/CD runners, appliances, and golden images.
• Prioritize patching of multi-user systems, container platforms, internet-facing Linux servers, bastion hosts, and systems that execute untrusted code.
• Apply vendor kernel updates that include the futex requeue flag-consistency fix and reboot into the patched kernel.
• Verify the running kernel version after reboot and track exceptions where systems remain on vulnerable kernels.
• Increase monitoring for suspicious local privilege-escalation behavior on unpatched systems, including crashes, unusual futex syscall activity, unexpected root shells, and privilege boundary changes.
• Restrict local access and untrusted workload execution on systems that cannot be patched promptly.
• Update base images, cloud templates, and appliance firmware so newly provisioned systems do not reintroduce vulnerable kernels.
• Because the vulnerability is not currently in KEV, has very low EPSS, and has no reported public exploit maturity, handle through an expedited but risk-based kernel patch process rather than emergency incident response unless exploitation evidence appears.