Re: [PATCH mm-hotfixes] mm/huge_memory: fix memory corruption on huge zero page move

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/3/26 08:25, Lorenzo Stoakes wrote:
> On Mon, Mar 02, 2026 at 12:50:32PM -0800, Andrew Morton wrote:
>> On Mon, 2 Mar 2026 17:19:15 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>>
>>>
>>> Yup, if people would actually cc the right people I'd not have wasted my
>>> afternoon.
>>>
>>> Replying there.
>>>
>>
>> I'm not sure where this is headed but I'll queue this patch for now, to
>> get it some testing, to lessen duplicated bug reports and to generally track things.
> 
> Hi Andrew -
> 
> We should drop my patch and take Chris's.
> 
> However, life isn't so simple :) as there's been some confusion with his series
> since his email client seemed to mess up somehow and a couple patches need to be
> squashed on one another.
> 
> So to make life easier, I enclose a squashed patch (combining the commit
> message from both), with my R-b, T-b tags attached, please replace my patch
> with this one.
> 
> Also, could you make this into a 2 patch series with
> https://lore.kernel.org/linux-mm/aaBWG4fajXXbjpVN@chrisdown.name/ _after_ this
> one?
> 
> mm-unstable (I'm not sure why we're rushing changes there so quick...) had
> _only_ this regression test patch in it, so we were left with a kernel that
> splatted on running mm selftests, which is not what we want.
> 
> (It seems to me this is what mm-new is for, and it seems we have some holes in
> our testing still since this got thorugh).
> 
> Please drop the patch you have for this already in mm-unstable and make sure we
> only have it _after_ the fix is applied :)
> 
> Thanks, Lorenzo
> 
> ----8<----
> From fbabbc38c000308d2c621a4b3ec1f4bca1d71c1d Mon Sep 17 00:00:00 2001
> From: Chris Down <chris@chrisdown.name>
> Date: Tue, 3 Mar 2026 07:21:21 +0000
> Subject: [PATCH] mm/huge_memory: Fix use of NULL folio in
>  move_pages_huge_pmd()
> 
> move_pages_huge_pmd() handles UFFDIO_MOVE for both normal THPs and huge
> zero pages. For the huge zero page path, src_folio is explicitly set to
> NULL, and is used as a sentinel to skip folio operations like lock and
> rmap.
> 
> In the huge zero page branch, src_folio is NULL, so folio_mk_pmd(NULL,
> pgprot) passes NULL through folio_pfn() and page_to_pfn(). With
> SPARSEMEM_VMEMMAP this silently produces a bogus PFN, installing a PMD
> pointing to non-existent physical memory. On other memory models it is a
> NULL dereference.
> 
> Use page_folio(src_page) to obtain the valid huge zero folio from the
> page, which was obtained from pmd_page() and remains valid throughout.
> 
> After commit d82d09e48219 ("mm/huge_memory: mark PMD mappings of the
> huge zero folio special"), moved huge zero PMDs must remain special so
> vm_normal_page_pmd() continues to treat them as special mappings.
> 
> move_pages_huge_pmd() currently reconstructs the destination PMD in the
> huge zero page branch, which drops PMD state such as pmd_special() on
> architectures with CONFIG_ARCH_HAS_PTE_SPECIAL. As a result,
> vm_normal_page_pmd() can treat the moved huge zero PMD as a normal page
> and corrupt its refcount.
> 
> Instead of reconstructing the PMD from the folio, derive the destination
> entry from src_pmdval after pmdp_huge_clear_flush(), then handle the PMD
> metadata the same way move_huge_pmd() does for moved entries by marking
> it soft-dirty and clearing uffd-wp.
> 
> Fixes: e3981db444a0 ("mm: add folio_mk_pmd()")
> Cc: stable@vger.kernel.org
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Tested-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Signed-off-by: Chris Down <chris@chrisdown.name>
> ---

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

-- 
Cheers,

David