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

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

[Jérémy Jean]

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.

Fixes: 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE")
Cc: stable@vger.kernel.org
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
---
 mm/khugepaged.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 4bbe319..e20416a 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -2251,6 +2251,13 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
 	 */
 	VM_WARN_ON_ONCE(!is_shmem && !mapping_pmd_folio_support(mapping));
 	VM_WARN_ON_ONCE(start & (HPAGE_PMD_NR - 1));
+	if (is_shmem)
+		inode_lock_shared(mapping->host);
+	if (is_shmem &&
+	    end > DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE)) {
+		result = SCAN_TRUNCATED;
+		goto out;
+	}
 
 	result = alloc_charge_folio(&new_folio, mm, cc, HPAGE_PMD_ORDER);
 	if (result != SCAN_SUCCEED)
@@ -2682,6 +2689,8 @@ rollback:
 out_put:
 	folio_put(new_folio);
 out:
+	if (is_shmem)
+		inode_unlock_shared(mapping->host);
 	VM_BUG_ON(!list_empty(&pagelist));
 	trace_mm_khugepaged_collapse_file(mm, new_pfn, index, addr, is_shmem, file, HPAGE_PMD_NR, result);
 	return result;
-- 
2.47.3

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

[Pedro Falcato]

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.

-- 
Pedro

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

[Andrew Morton]

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

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.

Jérémy , you haven't explained why this matters.  Is there some
userspace code which is encountering problems because of this?

Why did you propose cc:stable backporting?

Thanks.

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

[Baolin Wang]

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/

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] mm: xarray node memory leak in collapse_file() [1]
--

commit 8b05158695205f614e5dcb777a5926b63afd5388
Author: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>

mm/khugepaged: reject shmem collapse ranges beyond i_size

This commit holds the inode i_rwsem in shared mode during shmem collapse in
collapse_file() and rejects ranges extending beyond i_size rounded up to
PAGE_SIZE.

> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index c6d5ba6c88a6d..e0e602e8f87f1 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -2272,6 +2272,13 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
>  	 */
>  	VM_WARN_ON_ONCE(!is_shmem && !mapping_pmd_folio_support(mapping));
>  	VM_WARN_ON_ONCE(start & (HPAGE_PMD_NR - 1));
> +	if (is_shmem)
> +		inode_lock_shared(mapping->host);
> +	if (is_shmem &&
> +	    end > DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE)) {
> +		result = SCAN_TRUNCATED;
> +		goto out;
> +	}
>  
>  	result = alloc_charge_folio(&new_folio, mm, cc, HPAGE_PMD_ORDER);
>  	if (result != SCAN_SUCCEED)
> @@ -2703,6 +2710,8 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
>  out_put:
>  	folio_put(new_folio);
>  out:
> +	if (is_shmem)
> +		inode_unlock_shared(mapping->host);
>  	VM_BUG_ON(!list_empty(&pagelist));
>  	trace_mm_khugepaged_collapse_file(mm, new_pfn, index, addr, is_shmem, file, HPAGE_PMD_NR, result);
>  	return result;

[Severity: Medium]
This problem wasn't introduced by this patch, but can collapse_file() leak
a preallocated xa_node in xas.xa_alloc [1]?

mm/khugepaged.c:collapse_file() {
	...
	do {
		xas_lock_irq(&xas);
		xas_create_range(&xas);
		if (!xas_error(&xas))
			break;
		xas_unlock_irq(&xas);
		if (!xas_nomem(&xas, GFP_KERNEL)) {
			result = SCAN_FAIL;
			goto rollback;
		}
	} while (1);
	...
}

If xas_create_range() fails with -ENOMEM, xas_nomem() drops the lock and
caches a newly allocated xa_node in xas.xa_alloc.  If another thread
populates the XArray range before the lock is retaken, the next
xas_create_range() call succeeds without consuming xas.xa_alloc and breaks
out of the loop.  Because collapse_file() never calls xas_destroy(&xas)
before returning, that xa_node is leaked.

[1] https://sashiko.dev/#/bug/linux-2a262b48-1e7f-4d11-8b87-d5e410ce41f7

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112142335.2749597-2-Jeremy.Jean@oss.cyber.gouv.fr?part=1

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

[David Hildenbrand (Arm)]

On 11/13/26 15:25, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found no new issues
> in this patch, but noticed 1 related pre-existing issue it does not
> introduce:
> - [Medium] mm: xarray node memory leak in collapse_file() [1]
Ignore this shit from Sashiko.

Roman, make it stop.

-- 
Cheers,

David