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: <48978612-6933-4897-85DD-6740B6C8570B@nvidia.com>
Date: Wed, 04 Feb 2026 12:23:10 -0500
From: Zi Yan <ziy@...dia.com>
To: "David Hildenbrand (arm)" <david@...nel.org>
Cc: 是参差 <shicenci@...il.com>, linux-mm@...ck.org,
 linmiaohe@...wei.com, akpm@...ux-foundation.org,
 linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>
Subject: Re: WARNING in memory_failure() at include/linux/huge_mm.h:635
 triggered

On 4 Feb 2026, at 12:15, David Hildenbrand (arm) wrote:

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

>From the C repro above, syzbot opened a dev "/dev/sg#" and did mmap on it.
Is it a device driver issue?


--
Best Regards,
Yan, Zi