linux-kernel - Re: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in file_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] [thread-next>] [day] [month] [year] [list]

Message-ID: <cbf76e1d-6b5d-4072-9f46-027cea4c0478@kernel.org>
Date: Mon, 9 Feb 2026 11:41:52 +0100
From: "David Hildenbrand (Arm)" <david@...nel.org>
To: Deepanshu Kartikey <kartikey406@...il.com>, akpm@...ux-foundation.org,
 lorenzo.stoakes@...cle.com, baolin.wang@...ux.alibaba.com,
 Liam.Howlett@...cle.com, npache@...hat.com, ryan.roberts@....com,
 dev.jain@....com, baohua@...nel.org, ackerleytng@...gle.com,
 seanjc@...gle.com, pbonzini@...hat.com, michael.roth@....com,
 vannapurve@...gle.com
Cc: ziy@...dia.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 syzbot+33a04338019ac7e43a44@...kaller.appspotmail.com
Subject: Re: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in
 file_thp_enabled()

On 2/9/26 11:24, David Hildenbrand (Arm) wrote:
> On 2/9/26 04:35, Deepanshu Kartikey wrote:
>> file_thp_enabled() incorrectly returns true for guest_memfd and secretmem
>> inodes because they appear as regular read-only files when
>> CONFIG_READ_ONLY_THP_FOR_FS is enabled. This allows khugepaged and
>> MADV_COLLAPSE to create large folios in the page cache, but their fault
>> handlers do not support large folios.
>>
>> Add explicit checks for GUEST_MEMFD_MAGIC and SECRETMEM_MAGIC to reject
>> these filesystems early in file_thp_enabled().
>>
>> Reported-by: syzbot+33a04338019ac7e43a44@...kaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
>> Tested-by: syzbot+33a04338019ac7e43a44@...kaller.appspotmail.com
>> Signed-off-by: Deepanshu Kartikey <Kartikey406@...il.com>
> 
> So we were able to reproduce this with secretmem, right?
> 
> We want to add "Fixes:" for the introducing commits, which would be he 
> commits that enable secretmem and mapping of guest_memfd pages to user 
> space. Can you identify them?
> 
> And also
> 
>      Cc: stable@...r.kernel.org
> 
>> ---
>>   mm/huge_memory.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 40cf59301c21..4f57c78b57dd 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -93,6 +93,9 @@ static inline bool file_thp_enabled(struct 
>> vm_area_struct *vma)
>>           return false;
>>       inode = file_inode(vma->vm_file);
>> +    if (inode->i_sb->s_magic == GUEST_MEMFD_MAGIC ||
>> +        inode->i_sb->s_magic == SECRETMEM_MAGIC)
>> +        return false;
> 
> That's nasty. We want some way to identify that through the mapping.
> 
> Unfortunately CONFIG_READ_ONLY_THP_FOR_FS ignores any 
> mapping_set_large_folios() configs by design.
> 
> And CONFIG_READ_ONLY_THP_FOR_FS might go away soon, but we need a fix 
> until then.
> 
> While we can identify secretmem through vma_is_secretmem(), we can't do 
> the same for guest_memfd as it's built as a module.
> 
> Unfortunately AS_NO_DIRECT_MAP[1] won't work.
> 
> Maybe introduce a AS_NO_READ_ONLY_THP_FOR_FS, which we can just easily 
> rip out along with CONFIG_READ_ONLY_THP_FOR_FS later?

On second thought, why do we pass the

	!inode_is_open_for_write(inode)

in file_thp_enabled()?

Isn't that the main problem for these memfd things?

Maybe a get_write_access() is missing somewhere?

-- 
Cheers,

David