linux-kernel - Re: [PATCH v2 1/1] mm: prevent poison consumption when splitting THP

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: <cb58512e-e789-612a-7142-f0fdb505becf@huawei.com>
Date: Tue, 14 Oct 2025 10:42:39 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Qiuxu Zhuo <qiuxu.zhuo@...el.com>
CC: <ziy@...dia.com>, <baolin.wang@...ux.alibaba.com>,
	<Liam.Howlett@...cle.com>, <npache@...hat.com>, <ryan.roberts@....com>,
	<dev.jain@....com>, <baohua@...nel.org>, <nao.horiguchi@...il.com>,
	<farrah.chen@...el.com>, <jiaqiyan@...gle.com>, <lance.yang@...ux.dev>,
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
	<akpm@...ux-foundation.org>, <david@...hat.com>,
	<lorenzo.stoakes@...cle.com>, <tony.luck@...el.com>
Subject: Re: [PATCH v2 1/1] mm: prevent poison consumption when splitting THP

On 2025/10/11 15:55, Qiuxu Zhuo wrote:
> When performing memory error injection on a THP (Transparent Huge Page)
> mapped to userspace on an x86 server, the kernel panics with the following
> trace. The expected behavior is to terminate the affected process instead
> of panicking the kernel, as the x86 Machine Check code can recover from an
> in-userspace #MC.
> 
>   mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134
>   mce: [Hardware Error]: RIP 10:<ffffffff8372f8bc> {memchr_inv+0x4c/0xf0}
>   mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db
>   mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320
>   mce: [Hardware Error]: Run the above through 'mcelog --ascii'
>   mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel
>   Kernel panic - not syncing: Fatal local machine check
> 
> The root cause of this panic is that handling a memory failure triggered by
> an in-userspace #MC necessitates splitting the THP. The splitting process
> employs a mechanism, implemented in try_to_map_unused_to_zeropage(), which
> reads the sub-pages of the THP to identify zero-filled pages. However,
> reading the sub-pages results in a second in-kernel #MC, occurring before
> the initial memory_failure() completes, ultimately leading to a kernel
> panic. See the kernel panic call trace on the two #MCs.
> 
>   First Machine Check occurs // [1]
>     memory_failure()         // [2]
>       try_to_split_thp_page()
>         split_huge_page()
>           split_huge_page_to_list_to_order()
>             __folio_split()  // [3]
>               remap_page()
>                 remove_migration_ptes()
>                   remove_migration_pte()
>                     try_to_map_unused_to_zeropage()  // [4]
>                       memchr_inv()                   // [5]
>                         Second Machine Check occurs  // [6]
>                           Kernel panic
> 
> [1] Triggered by accessing a hardware-poisoned THP in userspace, which is
>     typically recoverable by terminating the affected process.
> 
> [2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page().
> 
> [3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page().
> 
> [4] Try to map the unused THP to zeropage.
> 
> [5] Re-access sub-pages of the hw-poisoned THP in the kernel.
> 
> [6] Triggered in-kernel, leading to a panic kernel.
> 
> In Step[2], memory_failure() sets the poisoned flag on the sub-page of the
> THP by TestSetPageHWPoison() before calling try_to_split_thp_page().
> 
> As suggested by David Hildenbrand, fix this panic by not accessing to the
> poisoned sub-page of the THP during zeropage identification, while
> continuing to scan unaffected sub-pages of the THP for possible zeropage
> mapping. This prevents a second in-kernel #MC that would cause kernel
> panic in Step[4].
> 
> [ Credits to Andrew Zaborowski <andrew.zaborowski@...el.com> for his
>   original fix that prevents passing the RMP_USE_SHARED_ZEROPAGE flag
>   to remap_page() in Step[3] if the THP has the has_hwpoisoned flag set,
>   avoiding access to the entire THP for zero-page identification. ]
> 
> Reported-by: Farrah Chen <farrah.chen@...el.com>
> Suggested-by: David Hildenbrand <david@...hat.com>
> Tested-by: Farrah Chen <farrah.chen@...el.com>
> Tested-by: Qiuxu Zhuo <qiuxu.zhuo@...el.com>
> Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@...el.com>
> ---
> v1 -> v2:
>   - Apply David Hildenbrand's fix suggestion.
> 
>   - Update the commit message to reflect the new fix.
> 
>   - Add David Hildenbrand's "Suggested-by:" tag.
> 
>   - Remove Andrew Zaborowski's SoB but add credits to him in the commit message.
>     [ I cannot reach him to get his SoB for the completely rewritten commit
>       message and new fix approach. ]
> 
>  mm/huge_memory.c | 3 +++
>  mm/migrate.c     | 3 ++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 

LGTM. Thanks for your fix.

Reviewed-by: Miaohe Lin <linmiaohe@...wei.com>

Thanks.
.