linux-kernel - [PATCH] 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-next>] [day] [month] [year] [list]

Message-Id: <20231013190929.17246-1-osmtendev@gmail.com>
Date:   Sat, 14 Oct 2023 00:09:29 +0500
From:   Osama Muhammad <osmtendev@...il.com>
To:     jack@...e.com
Cc:     linux-kernel@...r.kernel.org, Osama Muhammad <osmtendev@...il.com>,
        syzbot+abb7222a58e4ebc930ad@...kaller.appspotmail.com
Subject: [PATCH] UBSAN: array-index-out-of-bounds in udf_process_sequence

Syzkaller reported the following issue:

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]')
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>

The issue is caused when the value of i becomes equal or more than 4 which is
the size of array. In the code the condition checks the value of
spm->numSparingTables. syzbot was able to make spm->numSparingTables
value 4 which is cauing this error. The patch adds one more condition
to check the value of i should be less than 4.

Reported-and-tested-by: syzbot+abb7222a58e4ebc930ad@...kaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=abb7222a58e4ebc930ad
Signed-off-by: Osama Muhammad <osmtendev@...il.com>
---
 fs/udf/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/udf/super.c b/fs/udf/super.c
index 928a04d9d9e0..8c8731c3f8d9 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1361,7 +1361,7 @@ static int udf_load_sparable_map(struct super_block *sb,
 		return -EIO;
 	}
 
-	for (i = 0; i < spm->numSparingTables; i++) {
+	for (i = 0; i < spm->numSparingTables && i < 4; i++) {
 		loc = le32_to_cpu(spm->locSparingTable[i]);
 		bh = udf_read_tagged(sb, loc, loc, &ident);
 		if (!bh)
-- 
2.34.1