Re: [PATCH] mm: list_lru: fix NULL deref when a folio moves to the root memcg

[Shakeel Butt <shakeel.butt@linux.dev>]

On Thu, Nov 12, 2026 at 10:49:44AM +0800, Muchun Song wrote:
> 
> 
> > On Nov 12, 2026, at 10:41, Shakeel Butt <shakeel.butt@linux.dev> wrote:
> > 
> > folio_memcg_list_lru_alloc() makes sure that a folio's memcg has its
> > own lists in a list_lru, such as the THP deferred split queue. It looks
> > up the folio's memcg twice: a fast path under RCU checks if the lists
> > exist, and a slow path takes a reference and allocates them. The fast
> > path returns early for the root memcg, which uses the global lists.
> > The slow path does not check for the root.
> > 
> > The memcg can change between the two lookups: when a cgroup is
> > removed, its folios are moved to the parent memcg. If the folio is
> > moved up to the root in between, the slow path gets the root, and
> > __memcg_list_lru_alloc() dereferences the root's parent, which is NULL.
> > 
> > Users see a NULL pointer dereference oops while a THP is allocated,
> > such as in a page fault, in khugepaged or at swap-in. tmpfs huge pages
> > are affected too, and for them the oops can also happen in reclaim,
> > for example in kswapd. The task that hits the oops is killed, or the
> > machine panics if panic_on_oops is set.
> > 
> > The race is narrow: the folio has to be moved up to the root right
> > between the two lookups. For example, its cgroup is directly below the
> > root and is removed, or has its memory controller disabled, at that
> > moment.
> > 
> > Fix it by skipping the root memcg in the slow path too. The root needs
> > no lists of its own.
> > 
> > Fixes: ae64f07a6a40 ("mm: list_lru: introduce folio_memcg_list_lru_alloc()")
> > Reported-by: Chris Mason <mason@kernel.org>
> > Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
> > 
> > ---
> > mm/list_lru.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/mm/list_lru.c b/mm/list_lru.c
> > index d1d256822ccc..566691ca3dd8 100644
> > --- a/mm/list_lru.c
> > +++ b/mm/list_lru.c
> > @@ -645,9 +645,15 @@ int folio_memcg_list_lru_alloc(struct folio *folio, struct list_lru *lru,
> > 	if (likely(res))
> > 		return 0;
> > 
> > -	/* Allocation may block, pin the memcg */
> > +	/*
> > +	 * Allocation may block, so pin the memcg. If the folio's cgroup
> > +	 * was removed after the check above, the folio has moved up to a
> > +	 * parent memcg, which can be the root. The root uses the global
> > +	 * lists and has no parent, so skip it.
> > +	 */
> > 	memcg = get_mem_cgroup_from_folio(folio);
> > -	res = __memcg_list_lru_alloc(memcg, lru, gfp);
> > +	if (!mem_cgroup_is_root(memcg))
> 
> How about using memcg_list_lru_allocated() to check this, it's consistent with
> the above check?

Yes, that makes sense. Will send out v2.