CVE-2026-89985: memcg: keep folio's objcg same as its node
In the Linux kernel, the following vulnerability has been resolved:
memcg: keep folio's objcg same as its node
memcgreparentobjcgs() has an inherent assumption that a folio's objcg is the objcg of the folio's node. Folio migration across nodes breaks that assumption: the new folio simply inherits the old folio's objcg while living on a different node.
Once the assumption is broken, the reparenting of the folio's objcg and the reparenting of the folio's LRU list are no longer atomic. memcgreparentobjcgs() handles one node per iteration and drops all the locks in between, so the objcg gets reparented in the iteration for the objcg's node while the LRU list gets spliced in the iteration for the folio's node. Any LRU operation on that folio in between resolves its lruvec through the objcg, and thus takes the lrulock of the wrong memcg, not the lrulock of the list the folio is actually on.
Fix this by selecting the objcg by folionid() at charge time, and by re-deriving it for the destination node in memcgroupmigrate() and memcgroupreplacefolio().
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue is relevant where Linux kernel folios can migrate across NUMA nodes and memory cgroup object reparenting occurs. The problematic state arises when a migrated folio retains the object cgroup associated with its original node.
What can happen once the inconsistent folio and object-cgroup association exists?
During object-cgroup reparenting, the folio's object cgroup and LRU list can be handled in separate iterations with locks dropped between them. An LRU operation in that interval can resolve the folio's lruvec through the object cgroup and acquire the lock for the wrong memory cgroup rather than the lock for the list containing the folio.
How is the issue addressed in the resolved change?
The fix selects an object cgroup according to the folio's node when charging it. It also re-derives the object cgroup for the destination node during folio migration and folio replacement.