[lvc-project] Patch "erofs: Fix the slab-out-of-bounds in drop_buffers()" has been added to the 6.1-stable tree
gregkh at linuxfoundation.org
gregkh at linuxfoundation.org
Wed Apr 8 16:30:51 MSK 2026
This is a note to let you know that I've just added the patch titled
erofs: Fix the slab-out-of-bounds in drop_buffers()
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
erofs-fix-the-slab-out-of-bounds-in-drop_buffers.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable at vger.kernel.org> know about it.
>From arefev at swemel.ru Mon Mar 23 14:59:38 2026
From: Denis Arefev <arefev at swemel.ru>
Date: Mon, 23 Mar 2026 16:59:35 +0300
Subject: erofs: Fix the slab-out-of-bounds in drop_buffers()
To: stable at vger.kernel.org, Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Gao Xiang <xiang at kernel.org>, Chao Yu <chao at kernel.org>, Jeffle Xu <jefflexu at linux.alibaba.com>, linux-erofs at lists.ozlabs.org, linux-kernel at vger.kernel.org, lvc-project at linuxtesting.org, syzbot+5b886a2e03529dbcef81 at syzkaller.appspotmail.com
Message-ID: <20260323135936.15070-1-arefev at swemel.ru>
From: Denis Arefev <arefev at swemel.ru>
commit ce529cc25b184e93397b94a8a322128fc0095cbb upstream.
This was accidentally fixed in commit ce529cc25b18, but it's not possible
to accept all the changes, due to the lack of large folios support for
Linux 6.1 kernels, so this is only the actual bug fix that's needed.
[Background]
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 (such as
drop_buffers), which incorrectly treat folio->private as a list of
buffer_head structures, leading to incorrect memory interpretation and
out-of-bounds access.
Fix this by explicitly setting .release_folio and .invalidate_folio to the
values of iomap_release_folio and iomap_invalidate_folio, respectively.
[1] https://syzkaller.appspot.com/x/report.txt?x=12e5a142580000
Fixes: 7479c505b4ab ("fs: Convert iomap_readpage to iomap_read_folio")
Reported-by: syzbot+5b886a2e03529dbcef81 at syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=c6aeabd0c4ad2466f63a274faf2a123103f8fbf7
Signed-off-by: Denis Arefev <arefev at swemel.ru>
Reviewed-by: Gao Xiang <hsiangkao at linux.alibaba.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
fs/erofs/data.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/erofs/data.c
+++ b/fs/erofs/data.c
@@ -406,6 +406,8 @@ const struct address_space_operations er
.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
Patches currently in stable-queue which might be from arefev at swemel.ru are
queue-6.1/erofs-fix-the-slab-out-of-bounds-in-drop_buffers.patch
More information about the lvc-project
mailing list