CVE-2026-52973

What it actually does

This is a Linux kernel use-after-free flaw in futex handling. Under certain process-cloning patterns where tasks share an address space with CLONE_VM but are not conventional pthread-style CLONE_THREAD threads, the kernel can make incorrect assumptions about allocation and lifetime of the per-mm futex reference counter. That can leave futex cleanup paths, such as futex_hash_put, operating on memory that has already been freed. The observed failure mode is a kernel KASAN slab-use-after-free report; depending on kernel build, memory layout, and exploitability, the practical impact may range from local kernel crash to potential local privilege escalation if an attacker can reliably shape freed kernel memory.

Why it matters to the business

Successful exploitation would require local code execution on a vulnerable Linux system, but it could affect host stability and potentially compromise the underlying operating system if weaponized. For businesses, the most likely immediate consequence is service disruption from kernel crashes or instability on servers, containers hosts, workstations, appliances, or embedded Linux systems. The vulnerability is not currently in CISA KEV, is not known to be used in ransomware, has no reported exploit maturity, and has a very low EPSS score, so it should be handled through normal kernel patch management unless the systems are multi-user, container-dense, or exposed to untrusted local workloads.

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 process, malicious container workload, or untrusted local user session. The attacker then creates processes that share the same memory descriptor using CLONE_VM without following the expected CLONE_THREAD pthread semantics. By combining that process structure with futex activity and process teardown, the attacker attempts to trigger a race or lifetime mismatch in the kernel's per-mm futex reference tracking. In vulnerable kernels, the futex cleanup path can reference a stale per-CPU counter after the backing memory has been freed, producing a slab-use-after-free in futex_hash_put. A basic exploit may only crash the kernel, while a more advanced exploit would attempt to groom kernel heap state so the stale reference targets attacker-influenced memory and enables privilege escalation. No public exploitation or active threat-actor use is indicated by the provided data.

How to fix it

Apply a Linux kernel update that includes the upstream futex fix changing the private default hash allocation logic to cover CLONE_VM clones except vfork. Because no affected product list or fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Prioritize systems that run untrusted local users, shared shell access, CI/CD runners, container workloads, sandboxed applications, or multi-tenant compute. Where immediate patching is not possible, reduce exposure by limiting local code execution, isolating untrusted workloads, restricting container privileges, disabling unnecessary user access, and ensuring kernel crash recovery and monitoring are in place. Mitigations should not be treated as a substitute for patching because the flaw is in core kernel process and futex behavior.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a vendor kernel build containing the futex fix for this issue. Check the running kernel version with standard OS tooling and compare it against the distribution or vendor security advisory for the patched build. Where kernel live patching is used, confirm the live patch is loaded and applicable to the running kernel. Review package-manager history to ensure the kernel update was installed and the host rebooted into the corrected kernel, unless a validated live patch is in effect. For exposure validation, identify systems allowing local untrusted code execution or container workloads and verify they no longer run vulnerable kernel builds. For regression testing, monitor kernel logs after patching for futex-related warnings, KASAN reports, or crashes under workloads that use clone, shared memory, and futex-heavy concurrency.

Typical attack path

1. Gain local code execution on a vulnerable Linux host or within a workload that can invoke relevant clone and futex syscalls.
2. Create tasks that share an address space using CLONE_VM but are not created as normal CLONE_THREAD threads, excluding vfork-style execution.
3. Exercise futex operations while creating and tearing down the shared-mm task structure.
4. Trigger incorrect allocation or reference handling for the per-mm futex reference counter.
5. Cause futex cleanup, such as futex_hash_put, to operate on freed slab memory.
6. Use the resulting memory corruption to crash the kernel or, if exploitably controlled, attempt local privilege escalation.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dump metadata, kernel oops reports, KASAN output, EDR telemetry for local exploit attempts, and container-host audit logs. Focus on slab-use-after-free reports involving futex_hash_put or futex reference handling, kernel oops or panic events shortly after suspicious local process creation activity, and workloads making unusual clone/futex syscall patterns. If auditd or eBPF syscall telemetry is available, review processes invoking clone or clone3 with CLONE_VM without CLONE_THREAD followed by futex activity and abnormal termination. There are no known public actor-specific indicators in the provided data, so detection should be behavior- and artifact-based rather than signature-based.

• BUG: KASAN: slab-use-after-free in futex_hash_put
• slab-use-after-free in futex_hash_put
• futex_hash_put
• need_futex_hash_allocate_default
• mm->futex_ref
• KASAN: slab-use-after-free
• kernel BUG
• kernel oops
• Kernel panic
• CLONE_VM
• CLONE_THREAD
• clone3
• futex

What your security team should do

• Inventory Linux systems and prioritize patching for multi-user hosts, container hosts, CI runners, developer workstations, and systems executing untrusted code.
• Apply vendor-supplied kernel updates and reboot into the fixed kernel, or deploy a validated live patch where supported.
• Confirm that no systems remain booted into older vulnerable kernels after package installation.
• Increase monitoring for kernel oops, panic, KASAN, futex, and slab-use-after-free messages until patching is complete.
• Review local user and workload execution controls; restrict unnecessary shell access and avoid running untrusted containers with elevated privileges.
• For container platforms, ensure runtime isolation, seccomp, AppArmor/SELinux, and least-privilege profiles are enforced to reduce local kernel attack surface.
• Do not treat the low EPSS score as proof of safety on high-risk shared compute systems; local kernel flaws can become high impact if a separate initial-access path exists.