CVE-2026-89985

Published: Set 16, 2026 Last Modified: Set 16, 2026
ExploitDB:
Other exploit source:
Google Dorks:
HIGH 7,8
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Attack Vector: local
Attack Complexity: low
Privileges Required: low
User Interaction: none
Scope: unchanged
Confidentiality: high
Integrity: high
Availability: high

Description

AI Translation Available

In the Linux kernel, the following vulnerability has been resolved:

memcg: keep folio's objcg same as its node

memcg_reparent_objcgs() 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.
memcg_reparent_objcgs() 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 lru_lock of the wrong memcg,
not the lru_lock of the list the folio is actually on.

Fix this by selecting the objcg by folio_nid() at charge time, and by
re-deriving it for the destination node in mem_cgroup_migrate() and
mem_cgroup_replace_folio().

https://git.kernel.org/stable/c/6165478eaa3094eaee1d5e33b12520064faf043d
https://git.kernel.org/stable/c/bf4ade7dbd76d4ec8697840e4ebb15ed77c5ec26