Re: [PATCH] mm/khugepaged: reject shmem collapse ranges beyond i_size

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 11/13/26 6:50 AM, Andrew Morton wrote:
> On Thu, 12 Nov 2026 18:11:35 +0000 Pedro Falcato <pfalcato@suse.de> wrote:
> 
>> On Thu, Nov 12, 2026 at 02:23:35PM +0000, Jérémy Jean wrote:
>>> MADV_COLLAPSE lets collapse_file() treat absent shmem pages as holes
>>> filled with zeros. It does not check i_size, which allows one present
>>> page to become a huge mapping that covers the whole collapse range,
>>> including pages beyond EOF. This makes those pages writable. A later
>>> file extension can expose their contents after F_SEAL_WRITE.
>>>
>>> Hold inode i_rwsem in read mode while collapsing shmem so i_size
>>> cannot change. Reject a collapse if its page range extends past
>>> i_size rounded up to PAGE_SIZE. Keep i_size_read() outside the
>>> page-cache XArray lock because its 32-bit SMP reader is not IRQ
>>> safe.
>>
>> I don't think this is an issue. shmem/tmpfs purposefully maps with large pages
>> across i_size, and collapsing across i_size is a feature, not a bug.

Yes. finish_fault() even has comments explaining the special case for 
shmem/tmpfs.

	/*
	 * Do not allow to map with PTEs beyond i_size and with PMD
	 * across i_size to preserve SIGBUS semantics.
	 *
	 * Make an exception for shmem/tmpfs that for long time
	 * intentionally mapped with PMDs across i_size.
	 */
	needs_fallback = !shmem_mapping(mapping) &&
		file_end < folio_next_index(folio);

> hoo boy, this again, See
> https://lore-kernel.gnuweeb.org/linux-mm/nwkpojnictbg6jicccpxyfi63ol4tmfajrlx24u5xxoxx7lv5f@jkw3o7j6tlfs/T/
> and enjoy.
> 
> It's not good that this sequence permits non-zero data to be exposed in
> areas which ftruncate() created - the ftruncate() contract says it
> doesn't do that.

That's a valid concern and this is a known issue for shmem/tmpfs. Brian 
previously posted a patchset to fix it:
https://lore.kernel.org/all/20251112162522.412295-1-bfoster@redhat.com/