CVE-2026-89985

The Linux kernel's memory cgroup (memcg) subsystem contains a race condition: the object-cgroup reparenting routine (memcg_reparent_objcgs) assumes a folio's objcg always belongs to the folio's NUMA node, but folio migration across nodes breaks that assumption, leaving objcg reparenting and LRU-list reparenting non-atomic. During the race window, an LRU operation on a migrated folio resolves its lock through the objcg and takes the lru_lock of the wrong memcg rather than the lock of the list the folio actually sits on, corrupting lock/list consistency. An attacker is a local user (per the CVSS local, low-privilege vector) able to induce charge/migration/reclaim activity on a system where cross-node folio migration occurs, potentially gaining kernel memory disclosure or corruption and, per the C:H/I:H/A:H scoring, privilege escalation or denial of service. Affected systems are Linux hosts with memory cgroups enabled, most plausibly multi-NUMA machines such as servers and cloud instances running untrusted local workloads. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation is known.

What to do: Apply a kernel update containing the fix once it reaches the stable branches you track (kernel.org stable trees and your distro's patched kernel packages), and prioritize multi-NUMA hosts that host untrusted local users or multi-tenant workloads. Until patched, restrict local shell access on multi-tenant NUMA servers and confirm exposure by checking NUMA topology (e.g., number of NUMA nodes reported by the platform) and whether memory cgroups are in use; verify the fix is present by confirming the memcg objcg is re-derived on migration in mem_cgroup_migrate()/mem_cgroup_replace_folio().