Re: [RFC PATCH] mm/truncate: fix data loss when splitting fails in truncate_inode_partial_folio()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing re-validation of `page_folio()` result after `folio_try_get()` enables TOCTOU race, leading to out-of-bounds page splits and kernel panics.
--

commit 34ec9be8b97f90a8067df5949df00d3bb219ade3
Author: Zhang Yi <yi.zhang@huawei.com>

mm/truncate: fix data loss when splitting fails in truncate_inode_partial_folio()

truncate_inode_partial_folio() splits a large folio so that the caller's
truncate loop can drop the in-range sub-folios while keeping the
out-of-range tail.

Link: https://lore.kernel.org/linux-fsdevel/anH-WKA1coW6wtfG@bfoster/

> diff --git a/mm/truncate.c b/mm/truncate.c
> index b58ba940be474..2ebb00f6c3793 100644
> --- a/mm/truncate.c
> +++ b/mm/truncate.c
> @@ -273,24 +283,28 @@ bool truncate_inode_partial_folio(struct folio *folio, loff_t start, loff_t end)
>  		if (!folio_test_large(folio2))
>  			goto out;
>  
> -		if (!folio_trylock(folio2))
> +		if (!folio_trylock(folio2)) {
> +			tail_isolated = false;
>  			goto out;
> +		}
>  
>  		/* make sure folio2 is large and does not change its mapping */
>  		if (folio_test_large(folio2) &&
> -		    folio2->mapping == folio->mapping)
> -			folio_split_or_unmap(folio2, split_at2, min_order);
> +		    folio2->mapping == folio->mapping &&
> +		    folio_split_or_unmap(folio2, split_at2, min_order))
> +			tail_isolated = false;

[Severity: High]
Does this code have a TOCTOU race that could lead to an out-of-bounds page
split?

In truncate_inode_partial_folio() in mm/truncate.c, a speculative folio
lookup occurs just prior to this block:

	split_at2 = folio_page(folio,
			PAGE_ALIGN_DOWN(offset + length) / PAGE_SIZE);
	folio2 = page_folio(split_at2);

	if (!folio_try_get(folio2))
		goto no_split;

Without a re-validation check after folio_try_get(), couldn't a concurrent
operation (like memory reclaim or shmem readahead reallocation) change the
compound structure of folio2?

If the compound structure changes, a thread could successfully take a
reference on the new, smaller folio2. However, split_at2 would now be
outside the bounds of this new folio2.

When folio2 is later passed into folio_split_or_unmap() in the modified
code above, would this out-of-bounds split_at2 cause a kernel panic via
VM_BUG_ON_FOLIO() inside folio_split(), or corrupt adjacent page structures
if debug is disabled?

Should there be a check like if (unlikely(page_folio(split_at2) != folio2))
added after folio_try_get() to stabilize the reference?

>  
>  		folio_unlock(folio2);
>  out:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903115018.2034541-1-yi.zhang@huaweicloud.com?part=1