linux-kernel - Re: [syzbot] [udf?] UBSAN: array-index-out-of-bounds in udf_process

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230821122348.p3nrq4ezfc5vk5ff@quack3>
Date:   Mon, 21 Aug 2023 14:23:48 +0200
From:   Jan Kara <jack@...e.cz>
To:     syzbot <syzbot+abb7222a58e4ebc930ad@...kaller.appspotmail.com>
Cc:     jack@...e.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [udf?] UBSAN: array-index-out-of-bounds in
 udf_process_sequence

On Sun 20-08-23 07:25:47, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    9e6c269de404 Merge tag 'i2c-for-6.5-rc7' of git://git.kern..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=139aa5efa80000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> dashboard link: https://syzkaller.appspot.com/bug?extid=abb7222a58e4ebc930ad
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=175ed6bba80000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=146c8923a80000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/1d01305b8482/disk-9e6c269d.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/d7317878934a/vmlinux-9e6c269d.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/a7333ff86494/bzImage-9e6c269d.xz
> mounted in repro #1: https://storage.googleapis.com/syzbot-assets/2ad8331a86f3/mount_0.gz
> mounted in repro #2: https://storage.googleapis.com/syzbot-assets/049e481cc897/mount_8.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+abb7222a58e4ebc930ad@...kaller.appspotmail.com
> 
> UBSAN: array-index-out-of-bounds in fs/udf/super.c:1365:9
> index 4 is out of range for type '__le32[4]' (aka 'unsigned int[4]')

Frankly, the report doesn't make sense to me. The code looks like:

if (spm->numSparingTables > 4) {
	bail out
}

for (i = 0; i < spm->numSparingTables; i++) {
	loc = le32_to_cpu(spm->locSparingTable[i]);
...
}

and UBSAN complains when i == 4 which should not be possible. The only way
how I see this could be possible is when syzbot somehow manages to corrupt
the buffer 'spm' is stored in after we check it but so far I don't
see that in the reproducer and if that would really happen this would not
be anything to fix in UDF...

								Honza

> CPU: 0 PID: 6060 Comm: syz-executor319 Not tainted 6.5.0-rc6-syzkaller-00253-g9e6c269de404 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/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
>  udf_load_sparable_map fs/udf/super.c:1365 [inline]
>  udf_load_logicalvol fs/udf/super.c:1457 [inline]
>  udf_process_sequence+0x300d/0x4e70 fs/udf/super.c:1773
>  udf_load_sequence fs/udf/super.c:1820 [inline]
>  udf_check_anchor_block+0x2a6/0x550 fs/udf/super.c:1855
>  udf_scan_anchors fs/udf/super.c:1888 [inline]
>  udf_load_vrs+0x5ca/0x1100 fs/udf/super.c:1969
>  udf_fill_super+0x95d/0x23a0 fs/udf/super.c:2147
>  mount_bdev+0x276/0x3b0 fs/super.c:1391
>  legacy_get_tree+0xef/0x190 fs/fs_context.c:611
>  vfs_get_tree+0x8c/0x270 fs/super.c:1519
>  do_new_mount+0x28f/0xae0 fs/namespace.c:3335
>  do_mount fs/namespace.c:3675 [inline]
>  __do_sys_mount fs/namespace.c:3884 [inline]
>  __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861
>  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:0x7f363cae1c8a
> Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 3e 07 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffe6eac67a8 EFLAGS: 00000282 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f363cae1c8a
> RDX: 0000000020000100 RSI: 0000000020000340 RDI: 00007ffe6eac6800
> RBP: 00007ffe6eac6840 R08: 00007ffe6eac6840 R09: 0000000000000c35
> R10: 0000000000000000 R11: 0000000000000282 R12: 0000000020000340
> R13: 0000000020000100 R14: 0000000000000c3b R15: 0000000020020500
>  </TASK>
> ================================================================================
> 
> 
> ---
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR