Re: [PATCH] mm/sparse: Fix race on mem_section->usage in pfn walkers

Oscar Salvador
2026-04-15T08:38:01Z

On Wed, Apr 15, 2026 at 10:23:26AM +0800, Muchun Song wrote:
> When memory is hot-removed, section_deactivate() can tear down
> mem_section->usage while concurrent pfn walkers still inspect the
> subsection map via pfn_section_valid() or pfn_section_first_valid().
>
> After commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing
> memory_section->usage") converted the teardown to an RCU-based
> scheme, the code still relies on SECTION_HAS_MEM_MAP becoming visible
> to readers before ms->usage is cleared and queued for freeing.
>
> That ordering is not guaranteed. section_deactivate() can clear
> ms->usage and queue kfree_rcu() before another CPU observes the
> SECTION_HAS_MEM_MAP clear. A concurrent pfn walker can therefore see
> valid_section() return true, enter its sched-RCU read-side critical
> section after kfree_rcu() has already been queued, and then dereference
> a stale ms->usage pointer.
>
> And pfn_to_online_page() can call pfn_section_valid() without its
> own sched-RCU read-side critical section, which has similar problem.
>
> The race looks like this:
>
> compact_zone() memunmap_pages
> ============== ==============
> __remove_pages()->
> sparse_remove_section()->
> section_deactivate():
> a) [ Clear SECTION_HAS_MEM_MAP
> is reordered to b) ]
> kfree_rcu(ms->usage)
> __pageblock_pfn_to_page
> ......
> pfn_valid():
> rcu_read_lock_sched()
> valid_section() // return true
> pfn_section_valid()
> [Access ms->usage which is UAF]
> WRITE_ONCE(ms->usage, NULL)
> rcu_read_unlock_sched() b) Clear SECTION_HAS_MEM_MAP
>
> Fix this by using rcu_replace_pointer() when clearing ms->usage in
> section_deactivate(), then it does not rely on the order of clearing
> of SECTION_HAS_MEM_MAP.

The fix itself does not look too intrusive and I guess it kind of makes
sense when you think about the ordering issue, so if we want to be
rock solid, why not.
Does it slow down operations a lot?

I would also point out that you rcu-protect pfn_section_valid().

Regarding the pfn_to_online_page() race, that is something that every now
and then pops up, but as David said, we never seen that happening in the
wild so I guess no one really made the time to look into that.

--
Oscar Salvador
SUSE Labs