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: [email protected]
==================================================================
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 [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot <[email protected]> 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: [email protected]
>
> ==================================================================
> 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 [email protected].
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On Thu, Jun 24, 2021 at 7:31 AM Eric W. Biederman <[email protected]> wrote:
>
> syzbot <[email protected]> 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: [email protected]
> >
> > ==================================================================
> > 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 [email protected].
> >
> > 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/87fsx7akyf.fsf%40disp2133.
Dmitry Vyukov <[email protected]> writes:
> On Thu, Jun 24, 2021 at 7:31 AM Eric W. Biederman <[email protected]> wrote:
>>
>> syzbot <[email protected]> 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
On Fri, Jun 25, 2021 at 8:59 PM Eric W. Biederman <[email protected]> wrote:
>
> Dmitry Vyukov <[email protected]> writes:
>
> > On Thu, Jun 24, 2021 at 7:31 AM Eric W. Biederman <[email protected]> wrote:
> >>
> >> syzbot <[email protected]> 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?