Re:Re: [PATCH] mm/huge_memory: avoid TOCTOU race in min_order_for_split()

At 2026-08-04 18:04:15, "David Hildenbrand (Arm)" <[email protected]> wrote:
>On 8/4/26 05:58, [email protected] wrote:
>> From: liyouhong <[email protected]>
>> 
>> min_order_for_split() reads folio->mapping twice without any
>> synchronization. Concurrent truncate or invalidate can clear
>> folio->mapping between the check and subsequent function call.
>> Even with a held folio reference preventing the folio from
>> being freed, folio->mapping can still be overwritten to NULL. This
>> TOCTOU race allows passing a NULL mapping into mapping_min_folio_order(),
>> which leads to a NULL pointer dereference.
>> 
>> Cache folio->mapping to a local variable using READ_ONCE() to guarantee a
>> single memory load and remove the race window.
>
>In __folio_split() we hold the folio lock, so concurrent truncation is impossible.
>
>So is this about memory-failure.c ?
>
>We should rather fix that code to not call min_order_for_split() without the folio lock

>(we take it either way in try_to_split_thp_page), no?


Yes, you're right. The real issue is in memory-failure.c where the callers
do not hold the folio lock when calling min_order_for_split(). I'll send a
v2 that adds the folio lock at the call sites and also adds a
VM_WARN_ON_ONCE_FOLIO() in min_order_for_split() to catch any future
callers that don't hold the lock. Thanks for the review.

Cheers,
liyouhong