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: <0d9cada8-7148-4a5c-a09d-120ef54559d7@kernel.org>
Date: Mon, 9 Feb 2026 11:24:05 +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 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?


[1] https://lore.kernel.org/r/20260126164445.11867-6-kalyazin@amazon.com

-- 
Cheers,

David