lkml.org 
[lkml]   [2023]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
SubjectRe: [PATCH] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
From
On 10/11/23 1:46PM, Osama Muhammad wrote:
> Syzkaller reported the following issue:
>
> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
> index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
> CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
> ubsan_epilogue lib/ubsan.c:217 [inline]
> __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
> dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
> dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
> dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
> dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
> dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
> txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
> txUpdateMap+0x342/0x9e0
> txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
> jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
> kthread+0x2d3/0x370 kernel/kthread.c:388
> ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
> </TASK>
> ================================================================================
> Kernel panic - not syncing: UBSAN: panic_on_warn set ...
> CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
> panic+0x30f/0x770 kernel/panic.c:340
> check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
> ubsan_epilogue lib/ubsan.c:223 [inline]
> __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
> dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
> dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
> dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
> dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
> dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
> txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
> txUpdateMap+0x342/0x9e0
> txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
> jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
> kthread+0x2d3/0x370 kernel/kthread.c:388
> ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
> </TASK>
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
> The issue is caused when the value of lp becomes greater than
> CTLTREESIZE which is the max size of stree. Adding a simple check
> solves this issue. I was not sure about error return as a function
> does not return. If there is something needed in that regard please
> do point out.

There isn't too much we can do here without a bit of a code reorg. Even
the calling functions are void. We can't mark the filesystem dirty
easily either because we don't have a way to get to the superblock from
this function. I think I will change the test to
if (WARN_ON_ONCE(lp >= CTLTREESIZE))
for the lack of a better option.

Shaggy

>
> The patch is tested via syzbot.
>
> Reported-by: syzbot+39ba34a099ac2e9bd3cb@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=39ba34a099ac2e9bd3cb
> Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
> ---
> fs/jfs/jfs_dmap.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
> index a3eb1e826947..decb3be66a86 100644
> --- a/fs/jfs/jfs_dmap.c
> +++ b/fs/jfs/jfs_dmap.c
> @@ -2854,6 +2854,9 @@ static void dbAdjTree(dmtree_t * tp, int leafno, int newval)
> /* is the current value the same as the old value ? if so,
> * there is nothing to do.
> */
> + if (lp >= CTLTREESIZE)
> + return;
> +
> if (tp->dmt_stree[lp] == newval)
> return;
>

\
 
 \ /
  Last update: 2023-11-01 15:40    [W:1.563 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site