linux-kernel - Re: [PATCH 1/1] mm: Fix folio_pte_batch() overcount with zero PTEs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d53fd549-887f-4220-b0d1-ebc336eecb9f@redhat.com>
Date: Tue, 29 Apr 2025 16:29:30 +0200
From: David Hildenbrand <david@...hat.com>
To: Petr Vaněk <arkamar@...as.cz>,
 linux-kernel@...r.kernel.org
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Ryan Roberts <ryan.roberts@....com>, linux-mm@...ck.org,
 stable@...r.kernel.org
Subject: Re: [PATCH 1/1] mm: Fix folio_pte_batch() overcount with zero PTEs

On 29.04.25 16:22, Petr Vaněk wrote:
> folio_pte_batch() could overcount the number of contiguous PTEs when
> pte_advance_pfn() returns a zero-valued PTE and the following PTE in
> memory also happens to be zero. The loop doesn't break in such a case
> because pte_same() returns true, and the batch size is advanced by one
> more than it should be.
> 
> To fix this, bail out early if a non-present PTE is encountered,
> preventing the invalid comparison.
> 
> This issue started to appear after commit 10ebac4f95e7 ("mm/memory:
> optimize unmap/zap with PTE-mapped THP") and was discovered via git
> bisect.
> 
> Fixes: 10ebac4f95e7 ("mm/memory: optimize unmap/zap with PTE-mapped THP")
> Cc: stable@...r.kernel.org
> Signed-off-by: Petr Vaněk <arkamar@...as.cz>
> ---
>   mm/internal.h | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/mm/internal.h b/mm/internal.h
> index e9695baa5922..c181fe2bac9d 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -279,6 +279,8 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr,
>   			dirty = !!pte_dirty(pte);
>   		pte = __pte_batch_clear_ignored(pte, flags);
>   
> +		if (!pte_present(pte))
> +			break;
>   		if (!pte_same(pte, expected_pte))
>   			break;

How could pte_same() suddenly match on a present and non-present PTE.

Something with XEN is really problematic here.

-- 
Cheers,

David / dhildenb