Messages in this thread Patch in this message | | | Date | Wed, 1 Nov 2023 09:39:26 -0500 | Subject | Re: [PATCH] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree | From | Dave Kleikamp <> |
| |
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; >
| |