linux-kernel - Re: [PATCH] jfs: fix array-index-out-of-bounds in diNewExt

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

Message-ID: <1c5df433-ceb0-480b-8115-3e9fba3f52f3@oracle.com>
Date: Wed, 20 Dec 2023 14:02:28 -0600
From: Dave Kleikamp <dave.kleikamp@...cle.com>
To: Edward Adam Davis <eadavis@...com>,
        syzbot+553d90297e6d2f50dbc7@...kaller.appspotmail.com
Cc: jfs-discussion@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] jfs: fix array-index-out-of-bounds in diNewExt

On 12/11/23 7:36PM, Edward Adam Davis wrote:
> [Syz report]
> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
> index -878706688 is out of range for type 'struct iagctl[128]'
> CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/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
>   diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360
>   diAllocExt fs/jfs/jfs_imap.c:1949 [inline]
>   diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666
>   diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587
>   ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56
>   jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225
>   vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106
>   do_mkdirat+0x264/0x3a0 fs/namei.c:4129
>   __do_sys_mkdir fs/namei.c:4149 [inline]
>   __se_sys_mkdir fs/namei.c:4147 [inline]
>   __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147
>   do_syscall_x64 arch/x86/entry/common.c:51 [inline]
>   do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82
>   entry_SYSCALL_64_after_hwframe+0x63/0x6b
> RIP: 0033:0x7fcb7e6a0b57
> Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 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:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053
> RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57
> RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140
> RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> 
> [Analysis]
> When the agstart is too large, it can cause agno overflow.
> 
> [Fix]
> After obtaining agno, if the value is invalid, exit the subsequent process.

Looks good. Applied.

Shaggy

> 
> Reported-and-tested-by: syzbot+553d90297e6d2f50dbc7@...kaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@...com>
> ---
>   fs/jfs/jfs_imap.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/fs/jfs/jfs_imap.c b/fs/jfs/jfs_imap.c
> index a037ee59e398..cc5819b3ec9a 100644
> --- a/fs/jfs/jfs_imap.c
> +++ b/fs/jfs/jfs_imap.c
> @@ -2179,6 +2179,9 @@ static int diNewExt(struct inomap * imap, struct iag * iagp, int extno)
>   	/* get the ag and iag numbers for this iag.
>   	 */
>   	agno = BLKTOAG(le64_to_cpu(iagp->agstart), sbi);
> +	if (agno > MAXAG || agno < 0)
> +		return -EIO;
> +
>   	iagno = le32_to_cpu(iagp->iagnum);
>   
>   	/* check if this is the last free extent within the