[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxh2+fhAdpyu4JB93MGB9wV0ztExc6cWBZnhfLmozk8Fag@mail.gmail.com>
Date: Sat, 23 May 2020 12:17:10 +0300
From: Amir Goldstein <amir73il@...il.com>
To: syzbot <syzbot+61958888b1c60361a791@...kaller.appspotmail.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
overlayfs <linux-unionfs@...r.kernel.org>,
Miklos Szeredi <miklos@...redi.hu>,
Miklos Szeredi <mszeredi@...hat.com>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: KASAN: slab-out-of-bounds Read in ovl_check_fb_len
On Sat, May 23, 2020 at 1:23 AM syzbot
<syzbot+61958888b1c60361a791@...kaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: b85051e7 Merge tag 'fixes-for-5.7-rc6' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=165d2b81100000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b3368ce0cc5f5ace
> dashboard link: https://syzkaller.appspot.com/bug?extid=61958888b1c60361a791
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=168e6272100000
>
> The bug was bisected to:
>
> commit cbe7fba8edfc8cb8e621599e376f8ac5c224fa72
> Author: Amir Goldstein <amir73il@...il.com>
> Date: Fri Nov 15 11:33:03 2019 +0000
>
> ovl: make sure that real fid is 32bit aligned in memory
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11f95922100000
> final crash: https://syzkaller.appspot.com/x/report.txt?x=13f95922100000
> console output: https://syzkaller.appspot.com/x/log.txt?x=15f95922100000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+61958888b1c60361a791@...kaller.appspotmail.com
> Fixes: cbe7fba8edfc ("ovl: make sure that real fid is 32bit aligned in memory")
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in ovl_check_fb_len+0x171/0x1a0 fs/overlayfs/namei.c:89
> Read of size 1 at addr ffff88809727834d by task syz-executor.4/8488
>
> CPU: 0 PID: 8488 Comm: syz-executor.4 Not tainted 5.7.0-rc6-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x188/0x20d lib/dump_stack.c:118
> print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:382
> __kasan_report.cold+0x20/0x38 mm/kasan/report.c:511
> kasan_report+0x33/0x50 mm/kasan/common.c:625
> ovl_check_fb_len+0x171/0x1a0 fs/overlayfs/namei.c:89
> ovl_check_fh_len fs/overlayfs/overlayfs.h:358 [inline]
> ovl_fh_to_dentry+0x1ab/0x814 fs/overlayfs/export.c:812
> exportfs_decode_fh+0x11f/0x717 fs/exportfs/expfs.c:434
>
>
repro crafts a file handle
{ .handle_bytes = 2, .handle_type = OVL_FILEID_V1 }
handle_bytes gets rounded to 0, so we call
ovl_check_fh_len(f_handle, 0) => ovl_check_fb_len(f_handle + 3, -3)
I guess compiler may be evaluating the 2nd condition before the first:
if (fb_len < sizeof(struct ovl_fb) || fb_len < fb->len)
Silly thing is that Dan's patch that was just merged fixes a crash with:
{ .handle_bytes = 2, .handle_type = OVL_FILEID_V0 }
The original patch that he sent would have caught this case as well,
but I gave it a bad review comment, because I was too confident
about ovl_check_fh_len()'s safety.
But now I see that we also need to fix:
{ .handle_bytes = 4, .handle_type = OVL_FILEID_V0 }
which wasn't covered even with the original fix patch.
Let's try this fix:
#syz test: https://github.com/amir73il/linux.git ovl-fixes
Thanks,
Amir.
Powered by blists - more mailing lists