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: <4904d02f-6595-4230-a321-23327596e085@arm.com>
Date: Thu, 15 May 2025 13:52:50 +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 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.

> 
> 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.

> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ