[PATCH] mm/huge_memory: avoid transient none PMDs during lazyfree reclaim

[PATCH] mm/huge_memory: avoid transient none PMDs during lazyfree reclaim

[Kyle Zeng]

__discard_anon_folio_pmd_locked() clears and flushes a huge PMD before
checking whether the folio can be discarded. If the folio was redirtied
or has unexpected references, it restores the original PMD. Reclaim holds
the PMD lock and the anon_vma read lock, but not the owning mmap_lock.

Both zap_pmd_range() and mremap's get_old_pmd() can skip a none PMD
without taking its lock. A concurrent munmap() or whole-VMA
MREMAP_DONTUNMAP can therefore miss the PMD and later unlink the source
VMA from its anon_vma, leaving a restored mapping behind. The anon_vma
write lock taken by unlink_anon_vmas() waits for reclaim to finish, but
does not repeat the skipped page-table walk. Once the remaining VMA
links are removed, the folio's positive mapcount no longer guarantees a
live anon_vma. Racing lazyfree reclaim against MREMAP_DONTUNMAP as an
unprivileged user reproduces a KASAN use-after-free in
folio_lock_anon_vma_read().

Use pmdp_invalidate() to keep a recognizable, non-none huge PMD while
the discard can still fail. Concurrent unmap and move operations then
have to synchronize on the PMD lock instead of skipping the mapping.
Clear the invalidated PMD only after the dirty and reference checks have
succeeded, before removing the rmap and withdrawing the deposited page
table. The full invalidation retains the TLB flush required for the
dirty and GUP-fast checks.

Fixes: 735ecdfaf4e8 ("mm/vmscan: avoid split lazyfree THP during shrink_folio_list()")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-6-astra
Signed-off-by: Kyle Zeng <kylebot@openai.com>
---
 mm/huge_memory.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 1e5d68acf62a..20262195385a 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3569,11 +3569,17 @@ static bool __discard_anon_folio_pmd_locked(struct vm_area_struct *vma,
 		return false;
 	}
 
-	orig_pmd = pmdp_huge_clear_flush(vma, addr, pmdp);
+	/*
+	 * The discard may fail, so keep the PMD non-none until we're
+	 * committed to discarding it. Otherwise, concurrent munmap() or
+	 * mremap() can skip the PMD without taking the PTL and later unlink
+	 * the VMA from its anon_vma despite a restored mapping.
+	 */
+	orig_pmd = pmdp_invalidate(vma, addr, pmdp);
 
 	/*
 	 * Syncing against concurrent GUP-fast:
-	 * - clear PMD; barrier; read refcount
+	 * - invalidate PMD; barrier; read refcount
 	 * - inc refcount; barrier; read PMD
 	 */
 	smp_mb();
@@ -3607,6 +3613,7 @@ static bool __discard_anon_folio_pmd_locked(struct vm_area_struct *vma,
 		return false;
 	}
 
+	pmdp_huge_get_and_clear(mm, addr, pmdp);
 	folio_remove_rmap_pmd(folio, pmd_page(orig_pmd), vma);
 	zap_deposited_table(mm, pmdp);
 	add_mm_counter(mm, MM_ANONPAGES, -HPAGE_PMD_NR);

Re: [PATCH] mm/huge_memory: avoid transient none PMDs during lazyfree reclaim

[David Hildenbrand (Arm)]

On 10/9/26 18:52, Kyle Zeng wrote:
> __discard_anon_folio_pmd_locked() clears and flushes a huge PMD before
> checking whether the folio can be discarded. If the folio was redirtied
> or has unexpected references, it restores the original PMD. Reclaim holds
> the PMD lock and the anon_vma read lock, but not the owning mmap_lock.
> 
> Both zap_pmd_range() and mremap's get_old_pmd() can skip a none PMD
> without taking its lock. A concurrent munmap() or whole-VMA
> MREMAP_DONTUNMAP can therefore miss the PMD and later unlink the source
> VMA from its anon_vma, leaving a restored mapping behind. The anon_vma
> write lock taken by unlink_anon_vmas() waits for reclaim to finish, but
> does not repeat the skipped page-table walk. Once the remaining VMA
> links are removed, the folio's positive mapcount no longer guarantees a
> live anon_vma. Racing lazyfree reclaim against MREMAP_DONTUNMAP as an
> unprivileged user reproduces a KASAN use-after-free in
> folio_lock_anon_vma_read().
> 
> Use pmdp_invalidate() to keep a recognizable, non-none huge PMD while
> the discard can still fail. Concurrent unmap and move operations then
> have to synchronize on the PMD lock instead of skipping the mapping.
> Clear the invalidated PMD only after the dirty and reference checks have
> succeeded, before removing the rmap and withdrawing the deposited page
> table. The full invalidation retains the TLB flush required for the
> dirty and GUP-fast checks.
> 
> Fixes: 735ecdfaf4e8 ("mm/vmscan: avoid split lazyfree THP during shrink_folio_list()")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-6-astra
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> ---
>  mm/huge_memory.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 1e5d68acf62a..20262195385a 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3569,11 +3569,17 @@ static bool __discard_anon_folio_pmd_locked(struct vm_area_struct *vma,
>  		return false;
>  	}
>  
> -	orig_pmd = pmdp_huge_clear_flush(vma, addr, pmdp);
> +	/*
> +	 * The discard may fail, so keep the PMD non-none until we're
> +	 * committed to discarding it. Otherwise, concurrent munmap() or
> +	 * mremap() can skip the PMD without taking the PTL and later unlink
> +	 * the VMA from its anon_vma despite a restored mapping.
> +	 */

You can drop the entire comment. This is what we should do in most cases where
the mapping might be restored/changed, for example, in set_pmd_migration_entry().

> +	orig_pmd = pmdp_invalidate(vma, addr, pmdp);
>  
>  	/*
>  	 * Syncing against concurrent GUP-fast:
> -	 * - clear PMD; barrier; read refcount
> +	 * - invalidate PMD; barrier; read refcount
>  	 * - inc refcount; barrier; read PMD
>  	 */
>  	smp_mb();
> @@ -3607,6 +3613,7 @@ static bool __discard_anon_folio_pmd_locked(struct vm_area_struct *vma,
>  		return false;
>  	}
>  
> +	pmdp_huge_get_and_clear(mm, addr, pmdp);
>  	folio_remove_rmap_pmd(folio, pmd_page(orig_pmd), vma);
>  	zap_deposited_table(mm, pmdp);
>  	add_mm_counter(mm, MM_ANONPAGES, -HPAGE_PMD_NR);


Thanks!

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David

Re: [PATCH] mm/huge_memory: avoid transient none PMDs during lazyfree reclaim

[Zi Yan]

On Fri Oct 9, 2026 at 12:52 PM EDT, Kyle Zeng wrote:
> __discard_anon_folio_pmd_locked() clears and flushes a huge PMD before
> checking whether the folio can be discarded. If the folio was redirtied
> or has unexpected references, it restores the original PMD. Reclaim holds
> the PMD lock and the anon_vma read lock, but not the owning mmap_lock.
>
> Both zap_pmd_range() and mremap's get_old_pmd() can skip a none PMD
> without taking its lock. A concurrent munmap() or whole-VMA
> MREMAP_DONTUNMAP can therefore miss the PMD and later unlink the source
> VMA from its anon_vma, leaving a restored mapping behind. The anon_vma
> write lock taken by unlink_anon_vmas() waits for reclaim to finish, but
> does not repeat the skipped page-table walk. Once the remaining VMA
> links are removed, the folio's positive mapcount no longer guarantees a
> live anon_vma. Racing lazyfree reclaim against MREMAP_DONTUNMAP as an
> unprivileged user reproduces a KASAN use-after-free in
> folio_lock_anon_vma_read().
>
> Use pmdp_invalidate() to keep a recognizable, non-none huge PMD while
> the discard can still fail. Concurrent unmap and move operations then
> have to synchronize on the PMD lock instead of skipping the mapping.
> Clear the invalidated PMD only after the dirty and reference checks have
> succeeded, before removing the rmap and withdrawing the deposited page
> table. The full invalidation retains the TLB flush required for the
> dirty and GUP-fast checks.
>
> Fixes: 735ecdfaf4e8 ("mm/vmscan: avoid split lazyfree THP during shrink_folio_list()")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-6-astra
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> ---
>  mm/huge_memory.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 1e5d68acf62a..20262195385a 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3569,11 +3569,17 @@ static bool __discard_anon_folio_pmd_locked(struct vm_area_struct *vma,
>  		return false;
>  	}
>  
> -	orig_pmd = pmdp_huge_clear_flush(vma, addr, pmdp);
> +	/*
> +	 * The discard may fail, so keep the PMD non-none until we're
> +	 * committed to discarding it. Otherwise, concurrent munmap() or
> +	 * mremap() can skip the PMD without taking the PTL and later unlink
> +	 * the VMA from its anon_vma despite a restored mapping.
> +	 */
> +	orig_pmd = pmdp_invalidate(vma, addr, pmdp);

There are some gaps we need to close before getting this fix in:

1. GUP-fast cannot follow the invalidated PMD: riscv and LoongArch need
pmd_access_permitted() that requires _PAGE_PRESENT; s390's
pmdp_invalidate() needs a change.

2. sparc64's thp_pte_count can be imbalanced with this change (based on
Lance's offlist feedback).

In addition, powerpc has a page table check issue similr to riscv, where riscv
fixed it with commit 9f4a88b8d01a6. This is not related to this issue
but discovered along with the investigation.

>  
>  	/*
>  	 * Syncing against concurrent GUP-fast:
> -	 * - clear PMD; barrier; read refcount
> +	 * - invalidate PMD; barrier; read refcount
>  	 * - inc refcount; barrier; read PMD
>  	 */
>  	smp_mb();
> @@ -3607,6 +3613,7 @@ static bool __discard_anon_folio_pmd_locked(struct vm_area_struct *vma,
>  		return false;
>  	}
>  
> +	pmdp_huge_get_and_clear(mm, addr, pmdp);
>  	folio_remove_rmap_pmd(folio, pmd_page(orig_pmd), vma);
>  	zap_deposited_table(mm, pmdp);
>  	add_mm_counter(mm, MM_ANONPAGES, -HPAGE_PMD_NR);




-- 
Best Regards,
Yan, Zi

Re: [PATCH] mm/huge_memory: avoid transient none PMDs during lazyfree reclaim

[David Hildenbrand (Arm)]

On 10/9/26 20:17, Zi Yan wrote:
> On Fri Oct 9, 2026 at 12:52 PM EDT, Kyle Zeng wrote:
>> __discard_anon_folio_pmd_locked() clears and flushes a huge PMD before
>> checking whether the folio can be discarded. If the folio was redirtied
>> or has unexpected references, it restores the original PMD. Reclaim holds
>> the PMD lock and the anon_vma read lock, but not the owning mmap_lock.
>>
>> Both zap_pmd_range() and mremap's get_old_pmd() can skip a none PMD
>> without taking its lock. A concurrent munmap() or whole-VMA
>> MREMAP_DONTUNMAP can therefore miss the PMD and later unlink the source
>> VMA from its anon_vma, leaving a restored mapping behind. The anon_vma
>> write lock taken by unlink_anon_vmas() waits for reclaim to finish, but
>> does not repeat the skipped page-table walk. Once the remaining VMA
>> links are removed, the folio's positive mapcount no longer guarantees a
>> live anon_vma. Racing lazyfree reclaim against MREMAP_DONTUNMAP as an
>> unprivileged user reproduces a KASAN use-after-free in
>> folio_lock_anon_vma_read().
>>
>> Use pmdp_invalidate() to keep a recognizable, non-none huge PMD while
>> the discard can still fail. Concurrent unmap and move operations then
>> have to synchronize on the PMD lock instead of skipping the mapping.
>> Clear the invalidated PMD only after the dirty and reference checks have
>> succeeded, before removing the rmap and withdrawing the deposited page
>> table. The full invalidation retains the TLB flush required for the
>> dirty and GUP-fast checks.
>>
>> Fixes: 735ecdfaf4e8 ("mm/vmscan: avoid split lazyfree THP during shrink_folio_list()")
>> Cc: stable@vger.kernel.org
>> Assisted-by: Codex:gpt-6-astra
>> Signed-off-by: Kyle Zeng <kylebot@openai.com>
>> ---
>>  mm/huge_memory.c | 11 +++++++++--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 1e5d68acf62a..20262195385a 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -3569,11 +3569,17 @@ static bool __discard_anon_folio_pmd_locked(struct vm_area_struct *vma,
>>  		return false;
>>  	}
>>  
>> -	orig_pmd = pmdp_huge_clear_flush(vma, addr, pmdp);
>> +	/*
>> +	 * The discard may fail, so keep the PMD non-none until we're
>> +	 * committed to discarding it. Otherwise, concurrent munmap() or
>> +	 * mremap() can skip the PMD without taking the PTL and later unlink
>> +	 * the VMA from its anon_vma despite a restored mapping.
>> +	 */
>> +	orig_pmd = pmdp_invalidate(vma, addr, pmdp);
> 
> There are some gaps we need to close before getting this fix in:
> 
> 1. GUP-fast cannot follow the invalidated PMD: riscv and LoongArch need
> pmd_access_permitted() that requires _PAGE_PRESENT; s390's
> pmdp_invalidate() needs a change.

Ugh. We really need pmdp_invalidate() to have reasonable semantics. This whole
PMD locking is a mess :(

> 
> 2. sparc64's thp_pte_count can be imbalanced with this change (based on
> Lance's offlist feedback).

Ack.

> 
> In addition, powerpc has a page table check issue similr to riscv, where riscv
> fixed it with commit 9f4a88b8d01a6. This is not related to this issue
> but discovered along with the investigation.

Zi, do you have the capacity to take over this patch?

-- 
Cheers,

David

Re: [PATCH] mm/huge_memory: avoid transient none PMDs during lazyfree reclaim

[Zi Yan]

On 9 Oct 2026, at 16:23, David Hildenbrand (Arm) wrote:

> On 10/9/26 20:17, Zi Yan wrote:
>> On Fri Oct 9, 2026 at 12:52 PM EDT, Kyle Zeng wrote:
>>> __discard_anon_folio_pmd_locked() clears and flushes a huge PMD before
>>> checking whether the folio can be discarded. If the folio was redirtied
>>> or has unexpected references, it restores the original PMD. Reclaim holds
>>> the PMD lock and the anon_vma read lock, but not the owning mmap_lock.
>>>
>>> Both zap_pmd_range() and mremap's get_old_pmd() can skip a none PMD
>>> without taking its lock. A concurrent munmap() or whole-VMA
>>> MREMAP_DONTUNMAP can therefore miss the PMD and later unlink the source
>>> VMA from its anon_vma, leaving a restored mapping behind. The anon_vma
>>> write lock taken by unlink_anon_vmas() waits for reclaim to finish, but
>>> does not repeat the skipped page-table walk. Once the remaining VMA
>>> links are removed, the folio's positive mapcount no longer guarantees a
>>> live anon_vma. Racing lazyfree reclaim against MREMAP_DONTUNMAP as an
>>> unprivileged user reproduces a KASAN use-after-free in
>>> folio_lock_anon_vma_read().
>>>
>>> Use pmdp_invalidate() to keep a recognizable, non-none huge PMD while
>>> the discard can still fail. Concurrent unmap and move operations then
>>> have to synchronize on the PMD lock instead of skipping the mapping.
>>> Clear the invalidated PMD only after the dirty and reference checks have
>>> succeeded, before removing the rmap and withdrawing the deposited page
>>> table. The full invalidation retains the TLB flush required for the
>>> dirty and GUP-fast checks.
>>>
>>> Fixes: 735ecdfaf4e8 ("mm/vmscan: avoid split lazyfree THP during shrink_folio_list()")
>>> Cc: stable@vger.kernel.org
>>> Assisted-by: Codex:gpt-6-astra
>>> Signed-off-by: Kyle Zeng <kylebot@openai.com>
>>> ---
>>>  mm/huge_memory.c | 11 +++++++++--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index 1e5d68acf62a..20262195385a 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -3569,11 +3569,17 @@ static bool __discard_anon_folio_pmd_locked(struct vm_area_struct *vma,
>>>  		return false;
>>>  	}
>>>
>>> -	orig_pmd = pmdp_huge_clear_flush(vma, addr, pmdp);
>>> +	/*
>>> +	 * The discard may fail, so keep the PMD non-none until we're
>>> +	 * committed to discarding it. Otherwise, concurrent munmap() or
>>> +	 * mremap() can skip the PMD without taking the PTL and later unlink
>>> +	 * the VMA from its anon_vma despite a restored mapping.
>>> +	 */
>>> +	orig_pmd = pmdp_invalidate(vma, addr, pmdp);
>>
>> There are some gaps we need to close before getting this fix in:
>>
>> 1. GUP-fast cannot follow the invalidated PMD: riscv and LoongArch need
>> pmd_access_permitted() that requires _PAGE_PRESENT; s390's
>> pmdp_invalidate() needs a change.
>
> Ugh. We really need pmdp_invalidate() to have reasonable semantics. This whole
> PMD locking is a mess :(
>
>>
>> 2. sparc64's thp_pte_count can be imbalanced with this change (based on
>> Lance's offlist feedback).
>
> Ack.
>
>>
>> In addition, powerpc has a page table check issue similr to riscv, where riscv
>> fixed it with commit 9f4a88b8d01a6. This is not related to this issue
>> but discovered along with the investigation.
>
> Zi, do you have the capacity to take over this patch?

Yes, I can take over it. My plan is to send a series including
patches for 1 and this patch as is. powerpc fix can be a separate one.

Best Regards,
Yan, Zi

Re: [PATCH] mm/huge_memory: avoid transient none PMDs during lazyfree reclaim

[David Hildenbrand (Arm)]

On 10/9/26 22:27, Zi Yan wrote:
> On 9 Oct 2026, at 16:23, David Hildenbrand (Arm) wrote:
> 
>> On 10/9/26 20:17, Zi Yan wrote:
>>>
>>> There are some gaps we need to close before getting this fix in:
>>>
>>> 1. GUP-fast cannot follow the invalidated PMD: riscv and LoongArch need
>>> pmd_access_permitted() that requires _PAGE_PRESENT; s390's
>>> pmdp_invalidate() needs a change.
>>
>> Ugh. We really need pmdp_invalidate() to have reasonable semantics. This whole
>> PMD locking is a mess :(
>>
>>>
>>> 2. sparc64's thp_pte_count can be imbalanced with this change (based on
>>> Lance's offlist feedback).
>>
>> Ack.
>>
>>>
>>> In addition, powerpc has a page table check issue similr to riscv, where riscv
>>> fixed it with commit 9f4a88b8d01a6. This is not related to this issue
>>> but discovered along with the investigation.
>>
>> Zi, do you have the capacity to take over this patch?
> 
> Yes, I can take over it. My plan is to send a series including
> patches for 1 and this patch as is. powerpc fix can be a separate one.
> 
> Best Regards,
> Yan, Zi

If we need a quick stable fix we could temporarily disable the whole thing until
it is fixed, just a thought.

-- 
Cheers,

David