Syzbot has hit the following bug on current and all older kernels: BUG: KASAN: out-of-bounds in ext4_ext_rm_leaf fs/ext4/extents.c:2736 [inline] BUG: KASAN: out-of-bounds in ext4_ext_remove_space+0x2482/0x4d90 fs/ext4/extents.c:2958 Read of size 18446744073709551508 at addr ffff888073aea078 by task syz-executor420/6443
On investigation, I've found that eh->eh_entries is zero, ex is referring to last entry and EXT_LAST_EXTENT(eh) is referring to first. Hence EXT_LAST_EXTENT(eh) - ex becomes negative and causes the wrong buffer read.
element: FFFF8882F8F0D06C <----- ex element: FFFF8882F8F0D060 element: FFFF8882F8F0D054 element: FFFF8882F8F0D048 element: FFFF8882F8F0D03C element: FFFF8882F8F0D030 element: FFFF8882F8F0D024 element: FFFF8882F8F0D018 element: FFFF8882F8F0D00C <------ EXT_FIRST_EXTENT(eh) header: FFFF8882F8F0D000 <------ EXT_LAST_EXTENT(eh) and eh
Cc: stable@vger.kernel.org Reported-by: syzbot+6e5f2db05775244c73b7@syzkaller.appspotmail.com Closes: https://groups.google.com/g/syzkaller-bugs/c/G6zS-LKgDW0/m/63MgF6V7BAAJ Fixes: d583fb87a3ff ("ext4: punch out extents") Signed-off-by: Muhammad Usama Anjum usama.anjum@collabora.com --- This patch is only fixing the local issue. There may be bigger bug. Why is ex set to last entry if the eh->eh_entries is 0. If any ext4 developer want to look at the bug, please don't hesitate. --- fs/ext4/extents.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index e4115d338f101..7b7779b4cb87f 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -2726,7 +2726,7 @@ ext4_ext_rm_leaf(handle_t *handle, struct inode *inode, * If the extent was completely released, * we need to remove it from the leaf */ - if (num == 0) { + if (num == 0 && eh->eh_entries) { if (end != EXT_MAX_BLOCKS - 1) { /* * For hole punching, we need to scoot all the
Apologies for sending multiple copies of same email. There was some issue on my side.
On 9/11/23 2:40 PM, Muhammad Usama Anjum wrote:
Syzbot has hit the following bug on current and all older kernels: BUG: KASAN: out-of-bounds in ext4_ext_rm_leaf fs/ext4/extents.c:2736 [inline] BUG: KASAN: out-of-bounds in ext4_ext_remove_space+0x2482/0x4d90 fs/ext4/extents.c:2958 Read of size 18446744073709551508 at addr ffff888073aea078 by task syz-executor420/6443
On investigation, I've found that eh->eh_entries is zero, ex is referring to last entry and EXT_LAST_EXTENT(eh) is referring to first. Hence EXT_LAST_EXTENT(eh) - ex becomes negative and causes the wrong buffer read.
element: FFFF8882F8F0D06C <----- ex element: FFFF8882F8F0D060 element: FFFF8882F8F0D054 element: FFFF8882F8F0D048 element: FFFF8882F8F0D03C element: FFFF8882F8F0D030 element: FFFF8882F8F0D024 element: FFFF8882F8F0D018 element: FFFF8882F8F0D00C <------ EXT_FIRST_EXTENT(eh) header: FFFF8882F8F0D000 <------ EXT_LAST_EXTENT(eh) and eh
Cc: stable@vger.kernel.org Reported-by: syzbot+6e5f2db05775244c73b7@syzkaller.appspotmail.com Closes: https://groups.google.com/g/syzkaller-bugs/c/G6zS-LKgDW0/m/63MgF6V7BAAJ Fixes: d583fb87a3ff ("ext4: punch out extents") Signed-off-by: Muhammad Usama Anjum usama.anjum@collabora.com
This patch is only fixing the local issue. There may be bigger bug. Why is ex set to last entry if the eh->eh_entries is 0. If any ext4 developer want to look at the bug, please don't hesitate.
fs/ext4/extents.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index e4115d338f101..7b7779b4cb87f 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -2726,7 +2726,7 @@ ext4_ext_rm_leaf(handle_t *handle, struct inode *inode, * If the extent was completely released, * we need to remove it from the leaf */
if (num == 0) {
if (num == 0 && eh->eh_entries) { if (end != EXT_MAX_BLOCKS - 1) { /* * For hole punching, we need to scoot all the
linux-stable-mirror@lists.linaro.org
-
Muhammad Usama Anjum