[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lf6x4vp1.fsf@disp2133>
Date: Fri, 25 Jun 2021 13:59:22 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Dmitry Vyukov <dvyukov@...gle.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
Dmitry Vyukov <dvyukov@...gle.com> writes:
> 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.
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
Powered by blists - more mailing lists