On Wed, Dec 3, 2025 at 12:28 PM Sasha Levin sashal@kernel.org wrote:
From: Joanne Koong joannelkoong@gmail.com
[ Upstream commit 7aa6bc3e8766990824f66ca76c19596ce10daf3e ]
iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio.
Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.
Signed-off-by: Joanne Koong joannelkoong@gmail.com Tested-by: syzbot@syzkaller.appspotmail.com Reviewed-by: Brian Foster bfoster@redhat.com Reviewed-by: Christoph Hellwig hch@lst.de Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a comprehensive analysis. Let me compile my findings.
I don't think any filesystems had repercussions from this. afaik only inlined mappings are non-block-aligned and the underflow of length and the overflow of position when added together offset each other when determining how much to advance the iter for the next iteration. But I have no objection to this being backported to stable. I think if this gets backported, then we should also backport this one as well (https://lore.kernel.org/linux-fsdevel/20251111193658.3495942-3-joannelkoong@...).
Thanks, Joanne