Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <000000000000ef5d1b05c57c2262@google.com> <87fsx7akyf.fsf@disp2133>
 <CACT4Y+YM8wONCrOq75-TFwA86Sg5gRHDK81LQH_O_+yWsdTr=g@mail.gmail.com> <87lf6x4vp1.fsf@disp2133>
In-Reply-To: <87lf6x4vp1.fsf@disp2133>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Sat, 26 Jun 2021 07:17:09 +0200
Message-ID: <CACT4Y+YdFpx7-f-YwTnhj6Yy_aYGW7qkj+XV-7QT73DB2a=cmQ@mail.gmail.com>
Subject: Re: [syzbot] KASAN: out-of-bounds Read in do_exit
To:     "Eric W. Biederman" <ebiederm@xmission.com>
Cc:     syzbot <syzbot+b80bbdcca4c4dfaa189e@syzkaller.appspotmail.com>,
        akpm@linux-foundation.org, ast@kernel.org, christian@brauner.io,
        jnewsome@torproject.org, linux-kernel@vger.kernel.org,
        minchan@kernel.org, oleg@redhat.com,
        syzkaller-bugs@googlegroups.com, Ingo Molnar <mingo@kernel.org>,
        kasan-dev <kasan-dev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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?