linux-kernel - Re: [syzbot] KASAN: out-of-bounds Read in do

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]

Date:   Fri, 25 Jun 2021 16:39:46 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     syzbot <syzbot+b80bbdcca4c4dfaa189e@...kaller.appspotmail.com>,
        akpm@...ux-foundation.org, ast@...nel.org, christian@...uner.io,
        jnewsome@...project.org, linux-kernel@...r.kernel.org,
        minchan@...nel.org, oleg@...hat.com,
        syzkaller-bugs@...glegroups.com, Ingo Molnar <mingo@...nel.org>,
        kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: [syzbot] KASAN: out-of-bounds Read in do_exit

On Thu, Jun 24, 2021 at 7:31 AM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> syzbot <syzbot+b80bbdcca4c4dfaa189e@...kaller.appspotmail.com> writes:
>
> > Hello,
> >
> > syzbot found the following issue on:
>
> This looks like dueling debug mechanism.  At a quick glance
> stack_no_used is deliberately looking for an uninitialized part of the
> stack.
>
> Perhaps the fix is to make KASAN and DEBUG_STACK_USAGE impossible to
> select at the same time in Kconfig?

+kasan-dev

Hi Eric,

Thanks for looking into this.

I see several strange things about this KASAN report:
1. KASAN is not supposed to leave unused stack memory as "poisoned".
Function entry poisons its own frame and function exit unpoisions it.
Longjmp-like things can leave unused stack poisoned. We have
kasan_unpoison_task_stack_below() for these, so maybe we are missing
this annotation somewhere.

2. This stand-alone shadow pattern "07 07 07 07 07 07 07 07" looks fishy.
It means there are 7 good bytes, then 1 poisoned byte, then 7 good
bytes and so on. I am not sure what can leave such a pattern. Both
heap and stack objects have larger redzones in between. I am not sure
about globals, but stack should not overlap with globals (and there
are no modules on syzbot).

So far this happened only once and no reproducer. If nobody sees
anything obvious, I would say we just wait for more info.



> > HEAD commit:    9ed13a17 Merge tag 'net-5.13-rc7' of git://git.kernel.org/..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=116c517bd00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=bf635d6d1c7ebabc
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b80bbdcca4c4dfaa189e
> > compiler:       Debian clang version 11.0.1-2
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+b80bbdcca4c4dfaa189e@...kaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: out-of-bounds in stack_not_used include/linux/sched/task_stack.h:101 [inline]
> > BUG: KASAN: out-of-bounds in check_stack_usage kernel/exit.c:711 [inline]
> > BUG: KASAN: out-of-bounds in do_exit+0x1c6b/0x23d0 kernel/exit.c:869
> > Read of size 8 at addr ffffc90017d60400 by task loop0/31717
> >
> > CPU: 0 PID: 31717 Comm: loop0 Not tainted 5.13.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:79 [inline]
> >  dump_stack+0x202/0x31e lib/dump_stack.c:120
> >  print_address_description+0x5f/0x3b0 mm/kasan/report.c:233
> >  __kasan_report mm/kasan/report.c:419 [inline]
> >  kasan_report+0x15c/0x200 mm/kasan/report.c:436
> >  stack_not_used include/linux/sched/task_stack.h:101 [inline]
> >  check_stack_usage kernel/exit.c:711 [inline]
> >  do_exit+0x1c6b/0x23d0 kernel/exit.c:869
> >  kthread+0x3b8/0x3c0 kernel/kthread.c:315
> >  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
> >
> >
> > Memory state around the buggy address:
> >  ffffc90017d60300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >  ffffc90017d60380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>ffffc90017d60400: 07 07 07 07 07 07 07 07 00 00 00 00 00 00 00 00
> >                    ^
> >  ffffc90017d60480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >  ffffc90017d60500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ==================================================================
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@...glegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@...glegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/87fsx7akyf.fsf%40disp2133.