linux-kernel - Re: [PATCH] arm64: Check pxd_leaf() instead of !pxd

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <73a67d06-b497-40a2-8cb2-3b80c6ba59d1@arm.com>
Date: Thu, 15 May 2025 14:10:07 +0530
From: Dev Jain <dev.jain@....com>
To: David Hildenbrand <david@...hat.com>, catalin.marinas@....com,
 will@...nel.org
Cc: ryan.roberts@....com, anshuman.khandual@....com, mark.rutland@....com,
 yang@...amperecomputing.com, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, stable@...r.kernel.org
Subject: Re: [PATCH] arm64: Check pxd_leaf() instead of !pxd_table() while
 tearing down page tables



On 15/05/25 2:06 pm, David Hildenbrand wrote:
> On 15.05.25 10:22, Dev Jain wrote:
>>
>>
>> On 15/05/25 1:43 pm, David Hildenbrand wrote:
>>> On 15.05.25 08:34, Dev Jain wrote:
>>>> Commit 9c006972c3fe removes the pxd_present() checks because the caller
>>>> checks pxd_present(). But, in case of vmap_try_huge_pud(), the caller
>>>> only
>>>> checks pud_present(); pud_free_pmd_page() recurses on each pmd through
>>>> pmd_free_pte_page(), wherein the pmd may be none.
>>> The commit states: "The core code already has a check for pXd_none()",
>>> so I assume that assumption was not true in all cases?
>>>
>>> Should that one problematic caller then check for pmd_none() instead?
>>
>>   From what I could gather of Will's commit message, my interpretation is
>> that the concerned callers are vmap_try_huge_pud and vmap_try_huge_pmd.
>> These individually check for pxd_present():
>>
>> if (pmd_present(*pmd) && !pmd_free_pte_page(pmd, addr))
>>     return 0;
>>
>> The problem is that vmap_try_huge_pud will also iterate on pte entries.
>> So if the pud is present, then pud_free_pmd_page -> pmd_free_pte_page
>> may encounter a none pmd and trigger a WARN.
> 
> Yeah, pud_free_pmd_page()->pmd_free_pte_page() looks shaky.
> 
> I assume we should either have an explicit pmd_none() check in 
> pud_free_pmd_page() before calling pmd_free_pte_page(), or one in 
> pmd_free_pte_page().
> 
> With your patch, we'd be calling pte_free_kernel() on a NULL pointer, 
> which sounds wrong -- unless I am missing something important.
> 
>>
>>>
>>> If you were able to trigger this WARN, it's always a good idea to
>>> include the splat in the commit.
>>
>> I wasn't able to, it is just an observation from code inspection.
> 
> That better be included in the patch description :)

I did, actually. My bad for not putting in spaces, I notice now that the 
description looks horrible to the eye :)

>