Messages in this thread | | | From | Dmitry Vyukov <> | Date | Sat, 26 Jun 2021 07:17:09 +0200 | Subject | Re: [syzbot] KASAN: out-of-bounds Read in do_exit |
| |
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?
| |