lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 20 Jun 2023 15:24:59 -0500
From:   Dave Kleikamp <dave.kleikamp@...cle.com>
To:     anupsharma <anupnewsmail@...il.com>, r33s3n6@...il.com,
        mudongliangabcd@...il.com, liushixin2@...wei.com,
        wuhoipok@...il.com
Cc:     jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        skhan@...uxfoundation.org
Subject: Re: [PATCH] fs: jfs: fixed UBSAN: shift-out-of-bounds in dbFree

I want to apologize about this one. Recently, Siddh Raman Pant submitted 
a similar patch and I picked that one up. I'm sorry that I let yours get 
buried in my inbox, since it was submitted earlier.

I actually prefer his patch since it caught it earlier during mount 
time, but that's no excuse to not give you a more timely response.

Thanks,
Shaggy

On 4/14/23 8:53AM, anupsharma wrote:
> Syzkaller reported the following issue:
>           option from the mount to silence this warning.
> =======================================================
> find_entry called with index = 0
> read_mapping_page failed!
> ERROR: (device loop0): txCommit:
> ERROR: (device loop0): remounting filesystem as read-only
> ================================================================================
> UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:381:12
> shift exponent 134217736 is too large for 64-bit type 'long long'
> CPU: 1 PID: 5068 Comm: syz-executor350 Not tainted 6.3.0-rc2-syzkaller-00069-g0ddc84d2dd43 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/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_shift_out_of_bounds+0x3c3/0x420 lib/ubsan.c:387
>   dbFree+0x46e/0x650 fs/jfs/jfs_dmap.c:381
>   txFreeMap+0x96a/0xd50 fs/jfs/jfs_txnmgr.c:2510
>   xtTruncate+0xe5c/0x3260 fs/jfs/jfs_xtree.c:2467
>   jfs_free_zero_link+0x46e/0x6e0 fs/jfs/namei.c:758
>   jfs_evict_inode+0x35f/0x440 fs/jfs/inode.c:153
>   evict+0x2a4/0x620 fs/inode.c:665
>   __dentry_kill+0x436/0x650 fs/dcache.c:607
>   shrink_dentry_list+0x39c/0x6a0 fs/dcache.c:1201
>   shrink_dcache_parent+0xcd/0x480
>   do_one_tree+0x23/0xe0 fs/dcache.c:1682
>   shrink_dcache_for_umount+0x7d/0x120 fs/dcache.c:1699
>   generic_shutdown_super+0x67/0x340 fs/super.c:472
>   kill_block_super+0x7e/0xe0 fs/super.c:1398
>   deactivate_locked_super+0xa4/0x110 fs/super.c:331
>   cleanup_mnt+0x426/0x4c0 fs/namespace.c:1177
>   task_work_run+0x24a/0x300 kernel/task_work.c:179
>   exit_task_work include/linux/task_work.h:38 [inline]
>   do_exit+0x68f/0x2290 kernel/exit.c:869
>   do_group_exit+0x206/0x2c0 kernel/exit.c:1019
>   __do_sys_exit_group kernel/exit.c:1030 [inline]
>   __se_sys_exit_group kernel/exit.c:1028 [inline]
>   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1028
>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>   do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
>   entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7fa87e2289b9
> Code: Unable to access opcode bytes at 0x7fa87e22898f.
> RSP: 002b:00007fff4bfe3938 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> RAX: ffffffffffffffda RBX: 00007fa87e2a3330 RCX: 00007fa87e2289b9
> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001
> RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 00007fa87e29de40
> R10: 00007fff4bfe3850 R11: 0000000000000246 R12: 00007fa87e2a3330
> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
>   </TASK>
> ================================================================================
> 
> db_l2nbperpage which is used as a shift exponent to get the buffer
> for the current dmap will be less than and equal to 64.
> 
> Tested via syzbot.
> 
> Reported-by: syzbot+d2cd27dcf8e04b232eb2@...kaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?id=2a70a453331db32ed491f5cbb07e81bf2d225715
> 
> Signed-off-by: Anup Sharma <anupnewsmail@...il.com>
> ---
>   fs/jfs/jfs_dmap.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
> index a3eb1e826947..d2cf56dd8f91 100644
> --- a/fs/jfs/jfs_dmap.c
> +++ b/fs/jfs/jfs_dmap.c
> @@ -184,7 +184,10 @@ int dbMount(struct inode *ipbmap)
>   		err = -EINVAL;
>   		goto err_release_metapage;
>   	}
> -
> +	if (bmp->db_l2nbperpage >= 64) {
> +		err = -EINVAL;
> +		goto err_release_metapage;
> +	}
>   	bmp->db_maxlevel = le32_to_cpu(dbmp_le->dn_maxlevel);
>   	bmp->db_maxag = le32_to_cpu(dbmp_le->dn_maxag);
>   	bmp->db_agpref = le32_to_cpu(dbmp_le->dn_agpref);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ