[syzbot] KASAN: out-of-bounds Read in do_exit

[syzbot]

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+b80bbd...@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 syzk...@googlegroups.com.

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

[Eric W. Biederman]

syzbot <syzbot+b80bbd...@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

[Dmitry Vyukov]

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

> --
> 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-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/87fsx7akyf.fsf%40disp2133.

[Eric W. Biederman]

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

[Dmitry Vyukov]

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?

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.