syzbot reports a WARN_ON in iomap_iter_done() when iter->pos advances
past the end of the current iomap during buffered writes.

This happens when a write completes and updates iter->pos beyond the
mapped extent before a new iomap is obtained, violating the invariant
that iter->pos must lie within the active iomap range.

Detect this condition early and mark the mapping stale so the iterator
restarts with a fresh iomap covering the current position.

Fixes: a66191c590b3b58eaff05d2277971f854772bd5b ("iomap: tighten iterator state validation")
Tested-by: Piyush Patle <piyushpatle288@gmail.com>
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Reported-by: syzbot+bd5ca596a01d01bfa083@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=bd5ca596a01d01bfa083
---
 fs/iomap/iter.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
index c04796f6e57f..466a12b0c094 100644
--- a/fs/iomap/iter.c
+++ b/fs/iomap/iter.c
@@ -111,6 +111,13 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
 			       &iter->iomap, &iter->srcmap);
 	if (ret < 0)
 		return ret;
+	if (iter->iomap.length &&
+	    iter->iomap.offset + iter->iomap.length <= iter->pos) {
+		iter->iomap.flags |= IOMAP_F_STALE;
+		iomap_iter_reset_iomap(iter);
+		return 1;
+	}
+
 	iomap_iter_done(iter);
 	return 1;
 }
-- 
2.34.1

On Mon, Feb 02, 2026 at 06:30:44PM +0530, Piyush Patle wrote:
> Closes: https://syzkaller.appspot.com/bug?id=bd5ca596a01d01bfa083

This link doesn't work.  And the commit log has zero details of what's
happening either.

On Mon, Feb 02, 2026 at 06:48:50AM -0800, Christoph Hellwig wrote:
> On Mon, Feb 02, 2026 at 06:30:44PM +0530, Piyush Patle wrote:
> > Closes: https://syzkaller.appspot.com/bug?id=bd5ca596a01d01bfa083
> 
> This link doesn't work.  And the commit log has zero details of what's
> happening either.

Looks like this one:

https://syzkaller.appspot.com/bug?extid=bd5ca596a01d01bfa083

but there's no reproducer.  Looks like it's through the blockdev rather
than a filesystem being involved.

On Mon, Feb 02, 2026 at 03:35:39PM +0000, Matthew Wilcox wrote:
> On Mon, Feb 02, 2026 at 06:48:50AM -0800, Christoph Hellwig wrote:
> > On Mon, Feb 02, 2026 at 06:30:44PM +0530, Piyush Patle wrote:
> > > Closes: https://syzkaller.appspot.com/bug?id=bd5ca596a01d01bfa083
> > 
> > This link doesn't work.  And the commit log has zero details of what's
> > happening either.
> 
> Looks like this one:
> 
> https://syzkaller.appspot.com/bug?extid=bd5ca596a01d01bfa083
> 
> but there's no reproducer.  Looks like it's through the blockdev rather
> than a filesystem being involved.

Let's wait for a reproducer.  The fix looks incorrect for anything I
could think of, so I'd rather fix a real bug.  Given that lack of
reproducer I'm also not confident that it fixes anything.  The fact
that the Fixes tag points to a merge commit doesn't really increase
the trust I have in it either.

On Mon, Feb 02, 2026 at 08:05:48AM -0800, Christoph Hellwig wrote:
> On Mon, Feb 02, 2026 at 03:35:39PM +0000, Matthew Wilcox wrote:
> > On Mon, Feb 02, 2026 at 06:48:50AM -0800, Christoph Hellwig wrote:
> > > On Mon, Feb 02, 2026 at 06:30:44PM +0530, Piyush Patle wrote:
> > > > Closes: https://syzkaller.appspot.com/bug?id=bd5ca596a01d01bfa083
> > > 
> > > This link doesn't work.  And the commit log has zero details of what's
> > > happening either.
> > 
> > Looks like this one:
> > 
> > https://syzkaller.appspot.com/bug?extid=bd5ca596a01d01bfa083
> > 
> > but there's no reproducer.  Looks like it's through the blockdev rather
> > than a filesystem being involved.
> 
> Let's wait for a reproducer.  The fix looks incorrect for anything I
> could think of, so I'd rather fix a real bug.  Given that lack of
> reproducer I'm also not confident that it fixes anything.  The fact
> that the Fixes tag points to a merge commit doesn't really increase
> the trust I have in it either.
> 
> 

+1 to this, FWIW. I've had that syzbot report marked in my inbox
expecting (hoping..) it would eventually spit out a reproducer to help
better characterize the cause.

This patch just appears to copy the warning check and force a lookup
cycle before we trigger it, which I don't think is doing us any favors.
At minimum we should have an understanding of precisely how this
happens.

Brian

iomap_iter_done() expects that the iterator position always lies within
the current iomap range.  However, during buffered writes combined with
truncate or overwrite operations, the iterator position can advance past
the end of the current iomap without the mapping being invalidated.

When this happens, iomap_iter_done() triggers a warning because
iomap.offset + iomap.length no longer covers iter->pos, even though this
state can legitimately occur due to extent invalidation or write completion
advancing the iterator position.

Detect this condition immediately after iomap_begin(), mark the mapping
as stale, reset the iterator state, and retry mapping from the current
position.  This ensures that iomap_end() invariants are preserved and
prevents spurious warnings.

Fixes: a66191c590b3b58eaff05d2277971f854772bd5b ("iomap: tighten iterator state validation")
Tested-by: Piyush Patle <piyushpatle288@gmail.com>
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Reported-by: syzbot+bd5ca596a01d01bfa083@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=bd5ca596a01d01bfa083
---
 fs/iomap/iter.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
index c04796f6e57f..466a12b0c094 100644
--- a/fs/iomap/iter.c
+++ b/fs/iomap/iter.c
@@ -111,6 +111,13 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
 			       &iter->iomap, &iter->srcmap);
 	if (ret < 0)
 		return ret;
+	if (iter->iomap.length &&
+	    iter->iomap.offset + iter->iomap.length <= iter->pos) {
+		iter->iomap.flags |= IOMAP_F_STALE;
+		iomap_iter_reset_iomap(iter);
+		return 1;
+	}
+
 	iomap_iter_done(iter);
 	return 1;
 }
-- 
2.34.1

syzbot reports a WARN_ON in iomap_iter_done() when iter->pos advances
past the end of the current iomap during buffered writes.

This happens when a write completes and updates iter->pos beyond the
mapped extent before a new iomap is obtained, violating the invariant
that iter->pos must lie within the active iomap range.

Detect this condition early and mark the mapping stale so the iterator
restarts with a fresh iomap covering the current position.

Fixes: a66191c590b3b58eaff05d2277971f854772bd5b ("iomap: tighten iterator state validation")
Tested-by: Piyush Patle <piyushpatle288@gmail.com>
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Reported-by: syzbot+bd5ca596a01d01bfa083@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=bd5ca596a01d01bfa083
---
 fs/iomap/iter.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
index c04796f6e57f..466a12b0c094 100644
--- a/fs/iomap/iter.c
+++ b/fs/iomap/iter.c
@@ -111,6 +111,13 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
 			       &iter->iomap, &iter->srcmap);
 	if (ret < 0)
 		return ret;
+	if (iter->iomap.length &&
+	    iter->iomap.offset + iter->iomap.length <= iter->pos) {
+		iter->iomap.flags |= IOMAP_F_STALE;
+		iomap_iter_reset_iomap(iter);
+		return 1;
+	}
+
 	iomap_iter_done(iter);
 	return 1;
 }
-- 
2.34.1