lkml.org 
[lkml]   [2020]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: KASAN: slab-out-of-bounds Read in ovl_check_fb_len
On Sat, May 23, 2020 at 1:23 AM syzbot
<syzbot+61958888b1c60361a791@syzkaller.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@gmail.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@syzkaller.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.

\
 
 \ /
  Last update: 2020-05-23 11:18    [W:0.035 / U:5.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site