linux-kernel - Re: WARNING in memory_failure() at include/linux/huge

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: <1db245a8-f9ab-42e4-8cc6-cc7562961921@kernel.org>
Date: Wed, 4 Feb 2026 18:15:38 +0100
From: "David Hildenbrand (arm)" <david@...nel.org>
To: 是参差 <shicenci@...il.com>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>
Cc: "linmiaohe@...wei.com" <linmiaohe@...wei.com>,
 "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Zi Yan <ziy@...dia.com>, Matthew Wilcox <willy@...radead.org>
Subject: Re: WARNING in memory_failure() at include/linux/huge_mm.h:635
 triggered

On 2/4/26 18:12, David Hildenbrand (arm) wrote:
> On 2/4/26 13:49, 是参差 wrote:
>> Hi,
>> I’m reporting a reproducible WARNING triggered in the hwpoison / 
>> memory_failure path when injecting a hardware-poison event via 
>> madvise(MADV_HWPOISON).
>>
>> The warning is triggered by a syzkaller C reproducer that:
>> maps a file-backed region with MAP_FIXED, touches related VMAs, and then
>> calls madvise() with MADV_HWPOISON over a large range.
>> The kernel reports a VM_WARN_ON_ONCE_FOLIO(1) from 
>> memory_failure() and points to include/linux/huge_mm.h:635, suggesting 
>> an unexpected folio/page state encountered while handling a poisoned 
>> compound/huge folio.
>>
>> The target page appears to be a compound head page (order:3) already 
>> marked hwpoison. memory_failure() seems to reach a branch that 
>> unconditionally warns (VM_WARN_ON_ONCE_FOLIO(1) at include/linux/ 
>> huge_mm.h:635), which usually indicates an “unreachable”/unexpected 
>> folio type or state transition in the huge/compound folio handling 
>> logic during hwpoison processing.
>>
>> This looks like a kernel-side invariant violation rather than a pure 
>> userspace misuse, since the warning is emitted from an unconditional 
>> VM_WARN_ON_ONCE_FOLIO(1) site.
>>
>> Reproducer:
>> C reproducer: https://pastebin.com/raw/UxennX2B
>> console output: https://pastebin.com/raw/wrhKRwZY
>> kernel config: https://pastebin.com/raw/dP93yBLn
>>
>> Kernel:
>>
>> HEAD commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
>>
>>   git tree: torvalds/linux
>>
>> kernel version: 6.19.0-rc7  (QEMU Ubuntu 24.10)
> 
> @Zi Yan, this is weird.
> 
> We run into the VM_WARN_ON_ONCE_FOLIO(1, folio); in min_order_for_split(),
> which is only active with !CONFIG_TRANSPARENT_HUGEPAGE.
> 
> But how do we get a large folio in that case? folio_test_large(folio) 
> succeeded.
> 
> I think we rules out hugetlb before in that function.
> 
> 
> Looking into the full console output, this is an order-3 folio (fully 
> mapped).
> 
> How do we end up with a large folio here? I am only aware of that 
> happening when something would
> allocate an order-3 compound page (not a folio) and map it into the page 
> tables. Yes, that
> is nasty and can still happen, not sure yet though whether that is 
> really what the reproducer
> triggers.

Looking again,

mapping:0000000000000000 index:0xffff88800fe2e600

At least mapping==0 could indicate a non-folio thing.

-- 
Cheers,

David