[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871rtiex4e.fsf@dja-thinkpad.axtens.net>
Date: Fri, 06 Dec 2019 00:10:41 +1100
From: Daniel Axtens <dja@...ens.net>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Dmitry Vyukov <dvyukov@...gle.com>,
syzbot <syzbot+82e323920b78d54aaed5@...kaller.appspotmail.com>,
kasan-dev <kasan-dev@...glegroups.com>,
Andrii Nakryiko <andriin@...com>,
Alexei Starovoitov <ast@...nel.org>, bpf <bpf@...r.kernel.org>,
Martin KaFai Lau <kafai@...com>,
LKML <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
Song Liu <songliubraving@...com>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
Yonghong Song <yhs@...com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>
Subject: Re: BUG: unable to handle kernel paging request in pcpu_alloc
Daniel Borkmann <daniel@...earbox.net> writes:
> On Thu, Dec 05, 2019 at 03:35:21PM +1100, Daniel Axtens wrote:
>> >> HEAD commit: 1ab75b2e Add linux-next specific files for 20191203
>> >> git tree: linux-next
>> >> console output: https://syzkaller.appspot.com/x/log.txt?x=10edf2eae00000
>> >> kernel config: https://syzkaller.appspot.com/x/.config?x=de1505c727f0ec20
>> >> dashboard link: https://syzkaller.appspot.com/bug?extid=82e323920b78d54aaed5
>> >> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=156ef061e00000
>> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11641edae00000
>> >>
>> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> >> Reported-by: syzbot+82e323920b78d54aaed5@...kaller.appspotmail.com
>> >
>> > +Daniel, is it the same as:
>> > https://syzkaller.appspot.com/bug?id=f6450554481c55c131cc23d581fbd8ea42e63e18
>> > If so, is it possible to make KASAN detect this consistently with the
>> > same crash type so that syzbot does not report duplicates?
>>
>> It looks like both of these occur immediately after failure injection. I
>> think my assumption that I could ignore the chance of failures in the
>> per-cpu allocation path will have to be revisited. That's annoying.
>>
>> I'll try to spin something today but Andrey feel free to pip me at the
>> post again :)
>>
>> I'm not 100% confident to call them dups just yet, but I'm about 80%
>> confident that they are.
>
> Ok. Double checked BPF side yesterday night, but looks sane to me and the
> fault also hints into pcpu_alloc() rather than BPF code. Daniel, from your
> above reply, I read that you are aware of how the bisected commit would
> have caused the fault?
Yes, this one is on me - I did not take into account the brutal
efficiency of the fault injector when implementing my KASAN support for
vmalloc areas. I have a fix, I'm just doing final tests now.
Regards,
Daniel
>
> Thanks,
> Daniel
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@...glegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20191205125900.GB29780%40localhost.localdomain.
Powered by blists - more mailing lists