Re: [PATCH 01/10] x86/mm: drop order parameter from free_pagetable()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Page table pages are freed to the buddy allocator before their parent entries are cleared, creating a use-after-free window for hardware MMU walkers.
--

--- Patch [1]: [PATCH 01/10] x86/mm: drop order parameter from free_pagetable() ---
commit 9c29ffca799af465974343eaff811f5b52635f1f
Author: David Hildenbrand (Arm) <david@kernel.org>

x86/mm: drop order parameter from free_pagetable()

All callers pass 0, so let's drop the parameter.

> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index d57f29ca23a5a..69e36f02a663a 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c

[ ... ]

> @@ -1060,7 +1057,7 @@ static void __meminit free_pte_table(pte_t *pte_start, pmd_t *pmd)
>  	}
>  
>  	/* free a pte table */
> -	free_pagetable(pmd_page(*pmd), 0);
> +	free_pagetable(pmd_page(*pmd));
>  	spin_lock(&init_mm.page_table_lock);
>  	pmd_clear(pmd);

[Severity: High]
This is a pre-existing issue, but does calling free_pagetable() before
pmd_clear() create a use-after-free window?

The PTE table page is freed to the allocator before the PMD entry pointing to
it is cleared. If the freed page is quickly reallocated and populated with
arbitrary data, could hardware speculative page table walks or lockless software
walkers (like ptdump) follow the still-valid PMD entry and interpret this
data as valid page table entries?

>  	spin_unlock(&init_mm.page_table_lock);

[ ... ]

> @@ -1078,7 +1075,7 @@ static void __meminit free_pmd_table(pmd_t *pmd_start, pud_t *pud)
>  	}
>  
>  	/* free a pmd table */
> -	free_pagetable(pud_page(*pud), 0);
> +	free_pagetable(pud_page(*pud));
>  	spin_lock(&init_mm.page_table_lock);
>  	pud_clear(pud);

[Severity: High]
This is a pre-existing issue, but does this create a similar use-after-free
window for the PMD table page?

The PMD table page is freed to the buddy allocator before the PUD entry
pointing to it is cleared here.

>  	spin_unlock(&init_mm.page_table_lock);

[ ... ]

> @@ -1096,7 +1093,7 @@ static void __meminit free_pud_table(pud_t *pud_start, p4d_t *p4d)
>  	}
>  
>  	/* free a pud table */
> -	free_pagetable(p4d_page(*p4d), 0);
> +	free_pagetable(p4d_page(*p4d));
>  	spin_lock(&init_mm.page_table_lock);
>  	p4d_clear(p4d);

[Severity: High]
This is a pre-existing issue, but does this create a similar use-after-free
window for the PUD table page?

The PUD table page is freed to the buddy allocator before the P4D entry
pointing to it is cleared here.

>  	spin_unlock(&init_mm.page_table_lock);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-bootmem_info_part2-v1-0-156ce4986598@kernel.org?part=1