linux-kernel - Re: [PATCH v3 2/3] mm/page_alloc: only free healthy pages in high-order has

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] [day] [month] [year] [list]

Message-ID: <671528cf-6fe8-464d-8028-ecd5822f9053@kernel.org>
Date: Thu, 15 Jan 2026 21:42:53 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Jiaqi Yan <jiaqiyan@...gle.com>, jackmanb@...gle.com, hannes@...xchg.org,
 linmiaohe@...wei.com, ziy@...dia.com, harry.yoo@...cle.com,
 willy@...radead.org
Cc: nao.horiguchi@...il.com, lorenzo.stoakes@...cle.com,
 william.roche@...cle.com, tony.luck@...el.com, wangkefeng.wang@...wei.com,
 jane.chu@...cle.com, akpm@...ux-foundation.org, osalvador@...e.de,
 muchun.song@...ux.dev, rientjes@...gle.com, duenwen@...gle.com,
 jthoughton@...gle.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com,
 mhocko@...e.com
Subject: Re: [PATCH v3 2/3] mm/page_alloc: only free healthy pages in
 high-order has_hwpoisoned folio

On 1/12/26 01:49, Jiaqi Yan wrote:
> At the end of dissolve_free_hugetlb_folio(), a free HugeTLB folio
> becomes non-HugeTLB, and it is released to buddy allocator
> as a high-order folio, e.g. a folio that contains 262144 pages
> if the folio was a 1G HugeTLB hugepage.
> 
> This is problematic if the HugeTLB hugepage contained HWPoison
> subpages. In that case, since buddy allocator does not check
> HWPoison for non-zero-order folio, the raw HWPoison page can
> be given out with its buddy page and be re-used by either
> kernel or userspace.


Do we really have to have all that complexity in free_frozen_pages().

Can't we hook into __update_and_free_hugetlb_folio() and just free the 
chunks there?

> 
> Memory failure recovery (MFR) in kernel does attempt to take
> raw HWPoison page off buddy allocator after
> dissolve_free_hugetlb_folio(). However, there is always a time
> window between dissolve_free_hugetlb_folio() frees a HWPoison
> high-order folio to buddy allocator and MFR takes HWPoison
> raw page off buddy allocator.

I wonder whether marking the pageblock as isolated before freeing it 
could work?

In that case, nobody will be able to allocate the page before we 
un-isolate it.

Just a thought: but when you are dealing with a possible race, you can 
avoid that race by prohibiting the intermediate allocation from 
happening in the first place.


Also, this is a lot of complexity. Was this issue already hit in the 
past or is it purely theoretical?

-- 
Cheers

David