All of lore.kernel.org
 help / color / mirror / Atom feed
* [syzbot] KASAN: out-of-bounds Read in do_exit
@ 2021-06-24  5:17 syzbot
  2021-06-24  5:30 ` Eric W. Biederman
  0 siblings, 1 reply; 5+ messages in thread
From: syzbot @ 2021-06-24  5:17 UTC (permalink / raw)
  To: akpm, ast, christian, ebiederm, jnewsome, linux-kernel, minchan,
	oleg, syzkaller-bugs

Hello,

syzbot found the following issue on:

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@syzkaller.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@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [syzbot] KASAN: out-of-bounds Read in do_exit
  2021-06-24  5:17 [syzbot] KASAN: out-of-bounds Read in do_exit syzbot
@ 2021-06-24  5:30 ` Eric W. Biederman
  2021-06-25 14:39   ` Dmitry Vyukov
  0 siblings, 1 reply; 5+ messages in thread
From: Eric W. Biederman @ 2021-06-24  5:30 UTC (permalink / raw)
  To: syzbot
  Cc: akpm, ast, christian, jnewsome, linux-kernel, minchan, oleg,
	syzkaller-bugs, Ingo Molnar

syzbot <syzbot+b80bbdcca4c4dfaa189e@syzkaller.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?

Eric

>
> 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@syzkaller.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@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [syzbot] KASAN: out-of-bounds Read in do_exit
  2021-06-24  5:30 ` Eric W. Biederman
@ 2021-06-25 14:39   ` Dmitry Vyukov
  2021-06-25 18:59     ` Eric W. Biederman
  0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Vyukov @ 2021-06-25 14:39 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: syzbot, akpm, ast, christian, jnewsome, linux-kernel, minchan,
	oleg, syzkaller-bugs, Ingo Molnar, kasan-dev

On Thu, Jun 24, 2021 at 7:31 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> syzbot <syzbot+b80bbdcca4c4dfaa189e@syzkaller.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@syzkaller.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@googlegroups.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@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/87fsx7akyf.fsf%40disp2133.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [syzbot] KASAN: out-of-bounds Read in do_exit
  2021-06-25 14:39   ` Dmitry Vyukov
@ 2021-06-25 18:59     ` Eric W. Biederman
  2021-06-26  5:17       ` Dmitry Vyukov
  0 siblings, 1 reply; 5+ messages in thread
From: Eric W. Biederman @ 2021-06-25 18:59 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: syzbot, akpm, ast, christian, jnewsome, linux-kernel, minchan,
	oleg, syzkaller-bugs, Ingo Molnar, kasan-dev

Dmitry Vyukov <dvyukov@google.com> writes:

> On Thu, Jun 24, 2021 at 7:31 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
>>
>> syzbot <syzbot+b80bbdcca4c4dfaa189e@syzkaller.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.


I may be mixing things up but on second glance this entire setup
feels very familiar.  I think this is the second time I have made
this request that the two pieces of debugging code play nice.

Perhaps it is a different piece of debugging code and KASAN that
I am remembering but I think this is the second time this issue has come
up.

Eric

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [syzbot] KASAN: out-of-bounds Read in do_exit
  2021-06-25 18:59     ` Eric W. Biederman
@ 2021-06-26  5:17       ` Dmitry Vyukov
  0 siblings, 0 replies; 5+ messages in thread
From: Dmitry Vyukov @ 2021-06-26  5:17 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: syzbot, akpm, ast, christian, jnewsome, linux-kernel, minchan,
	oleg, syzkaller-bugs, Ingo Molnar, kasan-dev

On Fri, Jun 25, 2021 at 8:59 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Dmitry Vyukov <dvyukov@google.com> writes:
>
> > On Thu, Jun 24, 2021 at 7:31 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
> >>
> >> syzbot <syzbot+b80bbdcca4c4dfaa189e@syzkaller.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.
>
>
> I may be mixing things up but on second glance this entire setup
> feels very familiar.  I think this is the second time I have made
> this request that the two pieces of debugging code play nice.
>
> Perhaps it is a different piece of debugging code and KASAN that
> I am remembering but I think this is the second time this issue has come
> up.

This is the only mention of DEBUG_STACK_USAGE on kasan-dev:
https://groups.google.com/g/kasan-dev/search?q=DEBUG_STACK_USAGE

Searching lore:
https://lore.kernel.org/lkml/?q=KASAN+%22DEBUG_STACK_USAGE%22

I found mention of:
kernel-hacking: move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE

Maybe you remember these 2?

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-06-26  5:17 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-24  5:17 [syzbot] KASAN: out-of-bounds Read in do_exit syzbot
2021-06-24  5:30 ` Eric W. Biederman
2021-06-25 14:39   ` Dmitry Vyukov
2021-06-25 18:59     ` Eric W. Biederman
2021-06-26  5:17       ` Dmitry Vyukov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.