[PATCH 6.1 0/1] erofs: Fix the slab-out-of-bounds in drop_buffers()

[PATCH 6.1 0/1] erofs: Fix the slab-out-of-bounds in drop_buffers()

[Denis Arefev]

Syzbot reported that a KASAN slab-out-of-bounds bug was discovered in the drop_buffers()
function [1].

The root cause is that erofs_raw_access_aops does not define .release_folio and
.invalidate_folio. When using iomap-based operations, folio->private may contain
iomap-specific data rather than buffer_heads. Without special handlers, the kernel
may fall back to generic functions (e.g., drop_buffers), which incorrectly treat
folio->private as a list of buffer_head structures, leading to incorrect memory
interpretation and out-of-bounds access.

This can be fixed by explicitly setting .release_folio and .invalidate_folio to 
iomap_release_folio and iomap_invalidate_folio, respectively, but there is a 
commit ce529cc25b184e93397b94a8a322128fc0095cbb in upstream  that implicitly 
fixes this bug.

Please commit it to the stable branch v6.1.y .

[1] https://syzkaller.appspot.com/bug?id=c6aeabd0c4ad2466f63a274faf2a123103f8fbf7

Jingbo Xu (1):
  erofs: enable large folios for iomap mode

 fs/erofs/data.c  | 2 ++
 fs/erofs/inode.c | 2 ++
 2 files changed, 4 insertions(+)

-- 
2.43.0

[PATCH 6.1 1/1] erofs: enable large folios for iomap mode

[Denis Arefev]

From: Jingbo Xu <jefflexu@linux.alibaba.com>                                                                               

commit ce529cc25b184e93397b94a8a322128fc0095cbb upstream. 

Enable large folios for iomap mode.  Then the readahead routine will
pass down large folios containing multiple pages.

Let's enable this for non-compressed format for now, until the
compression part supports large folios later.

When large folios supported, the iomap routine will allocate iomap_page
for each large folio and thus we need iomap_release_folio() and
iomap_invalidate_folio() to free iomap_page when these folios get
reclaimed or invalidated.

Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Link: https://lore.kernel.org/r/20221130060455.44532-1-jefflexu@linux.alibaba.com
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Signed-off-by: Denis Arefev <arefev@swemel.ru>
---
Link: https://syzkaller.appspot.com/bug?id=c6aeabd0c4ad2466f63a274faf2a123103f8fbf7
---
 fs/erofs/data.c  | 2 ++
 fs/erofs/inode.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/fs/erofs/data.c b/fs/erofs/data.c
index fe8ac0e163f7..c9526c627dda 100644
--- a/fs/erofs/data.c
+++ b/fs/erofs/data.c
@@ -403,6 +403,8 @@ const struct address_space_operations erofs_raw_access_aops = {
 	.readahead = erofs_readahead,
 	.bmap = erofs_bmap,
 	.direct_IO = noop_direct_IO,
+	.release_folio = iomap_release_folio,
+	.invalidate_folio = iomap_invalidate_folio,
 };
 
 #ifdef CONFIG_FS_DAX
diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c
index ad2a82f2eb4c..e457b8a59ee7 100644
--- a/fs/erofs/inode.c
+++ b/fs/erofs/inode.c
@@ -295,6 +295,8 @@ static int erofs_fill_inode(struct inode *inode)
 		goto out_unlock;
 	}
 	inode->i_mapping->a_ops = &erofs_raw_access_aops;
+	if (!erofs_is_fscache_mode(inode->i_sb))
+		mapping_set_large_folios(inode->i_mapping);
 #ifdef CONFIG_EROFS_FS_ONDEMAND
 	if (erofs_is_fscache_mode(inode->i_sb))
 		inode->i_mapping->a_ops = &erofs_fscache_access_aops;
-- 
2.43.0

Re: [PATCH 6.1 1/1] erofs: enable large folios for iomap mode

[Gao Xiang]

Hi Denis,

On 2026/3/23 15:48, Denis Arefev wrote:
> From: Jingbo Xu <jefflexu@linux.alibaba.com>
> 
> commit ce529cc25b184e93397b94a8a322128fc0095cbb upstream.
> 
> Enable large folios for iomap mode.  Then the readahead routine will
> pass down large folios containing multiple pages.
> 
> Let's enable this for non-compressed format for now, until the
> compression part supports large folios later.
> 
> When large folios supported, the iomap routine will allocate iomap_page
> for each large folio and thus we need iomap_release_folio() and
> iomap_invalidate_folio() to free iomap_page when these folios get
> reclaimed or invalidated.
> 
> Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> Reviewed-by: Chao Yu <chao@kernel.org>
> Link: https://lore.kernel.org/r/20221130060455.44532-1-jefflexu@linux.alibaba.com
> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> Signed-off-by: Denis Arefev <arefev@swemel.ru>

I think we have no plan to enable large folios for
Linux 6.1 kernels, if the following part is what you
need, how about just backporting the following snippet
with the updated commit message for some explanation:

> +	.release_folio = iomap_release_folio,
> +	.invalidate_folio = iomap_invalidate_folio,


Thanks,
Gao Xiang

Re: [PATCH 6.1 0/1] erofs: Fix the slab-out-of-bounds in drop_buffers()

[Gao Xiang]

Hi Denis,

On 2026/3/23 15:48, Denis Arefev wrote:
> Syzbot reported that a KASAN slab-out-of-bounds bug was discovered in the drop_buffers()
> function [1].
> 
> The root cause is that erofs_raw_access_aops does not define .release_folio and
> .invalidate_folio. When using iomap-based operations, folio->private may contain
> iomap-specific data rather than buffer_heads. Without special handlers, the kernel
> may fall back to generic functions (e.g., drop_buffers), which incorrectly treat
> folio->private as a list of buffer_head structures, leading to incorrect memory
> interpretation and out-of-bounds access.
> 
> This can be fixed by explicitly setting .release_folio and .invalidate_folio to
> iomap_release_folio and iomap_invalidate_folio, respectively, but there is a
> commit ce529cc25b184e93397b94a8a322128fc0095cbb in upstream  that implicitly
> fixes this bug.

See my previous reply to the patch.

Thanks,
Gao Xiang

> 
> Please commit it to the stable branch v6.1.y .
> 
> [1] https://syzkaller.appspot.com/bug?id=c6aeabd0c4ad2466f63a274faf2a123103f8fbf7
> 
> Jingbo Xu (1):
>    erofs: enable large folios for iomap mode
> 
>   fs/erofs/data.c  | 2 ++
>   fs/erofs/inode.c | 2 ++
>   2 files changed, 4 insertions(+)
>