CVE-2026-64418

What it actually does

This is a Linux kernel race condition in memory-control-group shrinker metadata teardown and expansion. A partially initialized or later-unwound shrinker_info structure can be published, observed by another CPU during shrinker expansion, and then freed without holding the same serialization lock. The resulting race can lead to use-after-free or double-free in kernel memory. Because the flaw is reachable from local kernel paths associated with cgroups/memory-management activity and has high confidentiality, integrity, and availability impact, a successful local attacker could potentially crash the system or manipulate freed kernel memory in a way that enables privilege escalation.

Why it matters to the business

Systems running vulnerable Linux kernels may be exposed to local denial of service or privilege escalation by a user or process that already has local execution. In multi-user servers, container hosts, CI runners, shared development systems, and platforms that allow untrusted workloads, this can turn limited code execution into full host compromise. The current EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, but kernel memory-corruption issues should still be prioritized where untrusted local users, containers, or sandboxed workloads are present.

How an attack unfolds

An attacker first obtains low-privileged local code execution, such as through a user shell, compromised application account, container workload, or build job. They then attempt to trigger concurrent memory cgroup creation/online paths and shrinker allocation/expansion activity so that one CPU publishes shrinker_info for a memcg while another CPU expands shrinker metadata. If allocation or cleanup occurs at the wrong time, stale shrinker_info memory can be freed while still being copied or freed again by another path. A reliable exploit would try to shape heap allocation and timing so the use-after-free or double-free corrupts controllable kernel memory rather than only causing a crash. The likely outcomes are local kernel panic, system instability, or, with sufficient exploit reliability, execution with kernel privileges.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the shrinker_info teardown race: teardown is serialized with shrinker_mutex and alloc_shrinker_info error cleanup remains inside the locked section. Because no product-specific affected or fixed versions were provided, use the security advisory and kernel package metadata from the relevant Linux distribution or vendor to identify the first fixed kernel for each supported release stream. Prioritize upgrades on systems that permit local users, run containers, host CI/CD workloads, or execute untrusted jobs. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted container execution, enforcing least privilege, disabling unnecessary workload creation paths, limiting cgroup delegation to untrusted users where feasible, and increasing monitoring for kernel crashes or memory-corruption warnings. Reboot into the fixed kernel after installation; installing kernel packages without rebooting usually does not remove exposure.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated. On Linux, compare `uname -r` with the distribution advisory's fixed kernel version and verify package manager output such as `rpm -q kernel`, `dpkg -l 'linux-image*'`, or the vendor's equivalent. Check whether the vendor changelog references the upstream fix for `mm: shrinker: fix shrinker_info teardown race with expansion`, `expand_shrinker_info`, `alloc_shrinker_info`, or `free_shrinker_info`. Validate that all nodes have rebooted into the patched kernel after package installation. For fleet validation, inventory kernel versions across servers, container hosts, virtualization hosts, and CI workers, and flag systems running vulnerable release streams. Where kernel live patching is used, confirm the live patch explicitly covers this memory-management fix; otherwise perform a normal kernel upgrade and reboot.

Typical attack path

1. Gain low-privileged local execution on a Linux system running a vulnerable kernel.
2. Create or manipulate cgroups/memory cgroups to exercise mem_cgroup_css_online and shrinker_info allocation paths.
3. Generate concurrent shrinker allocation or memory-pressure activity to force expand_shrinker_info and expand_one_shrinker_info execution on another CPU.
4. Trigger allocation failure or cleanup timing so published shrinker_info is torn down while another path still references it.
5. Exploit the resulting use-after-free or double-free to crash the kernel or attempt controlled kernel memory corruption.
6. If memory corruption is controlled, escalate privileges or escape a container/sandbox to gain host-level control.

How to detect it

Retrospective detection is difficult because successful exploitation occurs in kernel memory and may leave no application-level trace. Focus on kernel and system logs, crash dumps, audit records, and workload history. Review `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, pstore/ramoops records, kdump/vmcore artifacts, and hypervisor or cloud serial console logs for memory-corruption signatures near cgroup or shrinker activity. Look for kernel warnings or panics that mention `shrinker_info`, `expand_shrinker_info`, `expand_one_shrinker_info`, `alloc_shrinker_info`, `free_shrinker_info`, `mem_cgroup_css_online`, `kvfree_rcu`, `double free`, `use-after-free`, `slab`, `RCU`, or `KASAN`. Correlate such events with local user sessions, new containers, cgroup creation, CI jobs, memory-pressure tests, or suspicious processes launched shortly before the crash. If a vmcore is available, analyze it with the distribution's kernel debuginfo to determine whether the faulting stack includes the affected shrinker or memcg functions. Absence of these logs does not prove non-exploitation, especially if logs were lost during a panic or an attacker gained kernel privileges.

• shrinker_info
• expand_shrinker_info
• expand_one_shrinker_info
• alloc_shrinker_info
• free_shrinker_info
• mem_cgroup_css_online
• shrinker_memcg_alloc
• kvfree_rcu
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• double free
• BUG: unable to handle page fault
• kernel BUG at mm/
• general protection fault
• slab corruption
• RCU stall
• kernel panic
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/fs/pstore
• vmcore
• dmesg

What your security team should do

• Prioritize patching shared Linux systems, container hosts, CI runners, and any servers where low-privileged or untrusted local code can run.
• Inventory running kernel versions across the fleet and map them to vendor advisories for this kernel memory-management fix.
• Schedule reboots after kernel package updates and verify systems actually booted into the fixed kernel.
• Temporarily restrict cgroup delegation, untrusted containers, and local interactive access on high-risk systems until patched.
• Monitor kernel logs for use-after-free, double-free, slab corruption, RCU, KASAN, or panic messages involving shrinker or memcg code paths.
• Treat unexplained kernel crashes on vulnerable systems as potentially security relevant and preserve logs, crash dumps, and workload history for analysis.
• Because there is no known KEV listing, ransomware association, or mature public exploit reported, balance urgency against operational reboot requirements, but do not defer patching on multi-tenant or untrusted-workload hosts.