[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+b1Eq1eXcHJR4tVyn1746pBCNqie8yapuqM3+ry3wJX4g@mail.gmail.com>
Date: Mon, 19 Nov 2018 20:42:26 -0800
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: syzbot <syzbot+999bca54de2ee169c021@...kaller.appspotmail.com>,
Frédéric Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
syzkaller-bugs@...glegroups.com,
Thomas Gleixner <tglx@...utronix.de>,
netdev <netdev@...r.kernel.org>
Subject: Re: KASAN: use-after-free Read in tick_sched_handle (3)
On Mon, Nov 19, 2018 at 8:10 PM, Frederic Weisbecker
<frederic@...nel.org> wrote:
> On Mon, Nov 19, 2018 at 01:39:02PM -0800, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: bae4e109837b mlxsw: spectrum: Expose discard counters via ..
>> git tree: net-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=11b5e77b400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
>> dashboard link: https://syzkaller.appspot.com/bug?extid=999bca54de2ee169c021
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14b7d093400000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1487a225400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+999bca54de2ee169c021@...kaller.appspotmail.com
>>
>> IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
>> IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
>> 8021q: adding VLAN 0 to HW filter on device team0
>> ==================================================================
>> kasan: CONFIG_KASAN_INLINE enabled
>> BUG: KASAN: use-after-free in tick_sched_handle+0x16c/0x180
>> kernel/time/tick-sched.c:164
>
> So tick_sched_timer() -> tick_sched_handle() is passed regs returned by
> get_irq_regs() that seem to be junk.
>
> Those regs should come from smp_apic_timer_interrupt().
>
> Thoughts?
Looking at the reproducer it looks like some memory corruption in
networking stack. +netdev
Powered by blists - more mailing lists