[PATCH] iomap: guard io_size EOF trim against concurrent truncate underflow

[PATCH] iomap: guard io_size EOF trim against concurrent truncate underflow

[Morduan Zang]

iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF.  This trims io_size when a writeback range extends
past end_pos:

    ioend->io_size += map_len;
	if (ioend->io_offset + ioend->io_size > end_pos)
            ioend->io_size = end_pos - ioend->io_offset;

However, ioend can be created before a concurrent truncate shrinks
the file.  In that case, end_pos can move below ioend->io_offset
before the trim happens.  The subtraction then becomes negative, but
the result is stored in size_t io_size, causing an unsigned wrap to
a huge value.

A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.

Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset.  This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.

Fixes: 51d20d1dacbe ("iomap: fix zero padding data issue in concurrent append writes")
Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
---
 fs/iomap/ioend.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/iomap/ioend.c b/fs/iomap/ioend.c
index acf3cf98b23a..0c391a66db6f 100644
--- a/fs/iomap/ioend.c
+++ b/fs/iomap/ioend.c
@@ -297,8 +297,12 @@ ssize_t iomap_add_to_ioend(struct iomap_writepage_ctx *wpc, struct folio *folio,
 	 * appending writes.
 	 */
 	ioend->io_size += map_len;
-	if (ioend->io_offset + ioend->io_size > end_pos)
-		ioend->io_size = end_pos - ioend->io_offset;
+	if (ioend->io_offset + ioend->io_size > end_pos) {
+		if (end_pos > ioend->io_offset)
+			ioend->io_size = end_pos - ioend->io_offset;
+		else
+			ioend->io_size = 0;
+	}
 
 	wbc_account_cgroup_owner(wpc->wbc, folio, map_len);
 	return map_len;
-- 
2.50.1

Re: [PATCH] iomap: guard io_size EOF trim against concurrent truncate underflow

[Christoph Hellwig]

On Thu, Jun 18, 2026 at 01:38:20PM +0800, Morduan Zang wrote:
> However, ioend can be created before a concurrent truncate shrinks
> the file.  In that case, end_pos can move below ioend->io_offset
> before the trim happens.  The subtraction then becomes negative, but
> the result is stored in size_t io_size, causing an unsigned wrap to
> a huge value.
> 
> A wrapped io_size can mislead append detection and corrupt
> completion-time size handling, since filesystem end_io paths consume
> io_size for decisions such as on-disk EOF updates and unwritten/COW
> completion ranges.

Do you have examples for this?  I.e. did you hit this with a workload,
or did you just look over the code for issues?

> +	if (ioend->io_offset + ioend->io_size > end_pos) {
> +		if (end_pos > ioend->io_offset)
> +			ioend->io_size = end_pos - ioend->io_offset;
> +		else
> +			ioend->io_size = 0;
> +	}

I find this a bit hard to read due to different paramter ordering,
i.e. why not:

	if (ioend->io_offset + ioend->io_size > end_pos) {
		if (ioend->io_offset >= end_pos)
			ioend->io_size = 0;
		else
			ioend->io_size = end_pos - ioend->io_offset;
	}

Re: [PATCH] iomap: guard io_size EOF trim against concurrent truncate underflow

[Morduan Zang]

On Thu, Jun 18, 2026 at 01:38:20PM +0800, Christian Brauner wrote:
> Do you have examples for this?  I.e. did you hit this with a workload,
> or did you just look over the code for issues?

No, I do not have a workload reproducer. I noticed this while reviewing
the EOF trim in 51d20d1dacbe for backport — our static analysis flagged
that end_pos - ioend->io_offset is assigned to size_t without ensuring
end_pos >= ioend->io_offset.

I have not been able to trigger this in testing yet, so I do not want to
overstate the practical impact. That said, once the trim path is taken
with end_pos <= io_offset, the current code clearly wraps io_size, which
seems wrong relative to the intent of that commit (io_size should reflect
valid in-EOF data, i.e. zero in that case). Filesystem completion paths
also use io_size for range decisions beyond a simple EOF update.

If you consider this path unreachable in practice I am happy to drop the
patch. Otherwise, the guard itself is small and only affects the trim
branch — I can send a v2 with your suggested ordering if you think it is
worth hardening even without a reproducer.

> I find this a bit hard to read due to different paramter ordering,
> i.e. why not:
>
> if (ioend->io_offset + ioend->io_size > end_pos) {
>         if (ioend->io_offset >= end_pos)
>                 ioend->io_size = 0;
>         else
>                 ioend->io_size = end_pos - ioend->io_offset;
> }

If you are fine with this change, I will send a v2 with this ordering to
improve code quality.

Thanks,
Morduan Zang

Re: [PATCH] iomap: guard io_size EOF trim against concurrent truncate underflow

[Christoph Hellwig]

On Thu, Jun 18, 2026 at 07:03:07PM +0800, Morduan Zang wrote:
> No, I do not have a workload reproducer. I noticed this while reviewing
> the EOF trim in 51d20d1dacbe for backport — our static analysis flagged
> that end_pos - ioend->io_offset is assigned to size_t without ensuring
> end_pos >= ioend->io_offset.

Ok, makes sense.

> If you consider this path unreachable in practice I am happy to drop the
> patch. Otherwise, the guard itself is small and only affects the trim
> branch — I can send a v2 with your suggested ordering if you think it is
> worth hardening even without a reproducer.

I don't think it's impossible.  Just curious where this change comes
from and hoping for a reproducer if we can come up with one.