[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

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

[Roman Gushchin]

"David Hildenbrand (Arm)" <david@kernel.org> writes:

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

David, will do.

But also it's not how I want to interact on mailing lists tbh. I
understand everybody is stressed and overwhelmed by llms etc. Including
myself. If sashiko is not appreciated in mm lands, I can turn it off,
no problems from me.

Thanks

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

[David Hildenbrand (Arm)]

On 11/13/26 18:20, Roman Gushchin wrote:
> "David Hildenbrand (Arm)" <david@kernel.org> writes:
> 
>> 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.
> 
> David, will do.
> 
> But also it's not how I want to interact on mailing lists tbh.

Roman, just to be clear, I am talking about preexisting issues. We get bombarded
with preexisting issue reports. Having more duplicate reports posted to the
mailing list does not help anybody.

It creates more work for everybody. And the least I need right now is more work,
believe me.

> I understand everybody is stressed and overwhelmed by llms etc. Including
> myself. If sashiko is not appreciated in mm lands, I can turn it off,
> no problems from me.

Sashiko is great. The embargoed sending of mails to the list is great. I
appreciate all of that.

Posting preexisting stuff to the mailing list is not great, at least not right now.

We were very happy that preexisting issues went into the private bugtracker. I
want to delegate stuff to people in my team to screen them and see if it needs
fixing. Well controlled.

Now either:

(a) it was never really gone, and we were in disbelieve that preexisting issues
    are no longer posted publicly.

(b) Sashiko maintainer decided to re-enable it without consulting us.


I'm sorry if I made you angry, but I hope you can see how I suspect (b) and why
it would make me angry.

-- 
Cheers,

David