[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACT4Y+aYWgq853nPn3EoW4A0TU9pTJb+vwWHwTiguYy_T3K5rw@mail.gmail.com>
Date: Thu, 20 Aug 2020 19:15:16 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: syzbot <syzbot+df400f2f24a1677cd7e0@...kaller.appspotmail.com>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
bpf <bpf@...r.kernel.org>
Subject: Re: unregister_netdevice: waiting for DEV to become free (4)
On Thu, Aug 20, 2020 at 7:07 PM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
> > On Wed, Aug 19, 2020 at 3:54 PM syzbot
> > <syzbot+df400f2f24a1677cd7e0@...kaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: 18445bf4 Merge tag 'spi-fix-v5.9-rc1' of git://git.kernel...
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1710d97a900000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=bb68b9e8a8cc842f
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=df400f2f24a1677cd7e0
> > > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15859986900000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1228fea1900000
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+df400f2f24a1677cd7e0@...kaller.appspotmail.com
> > >
> > > unregister_netdevice: waiting for lo to become free. Usage count = 1
> >
> > Based on the repro, it looks bpf/bpf link related:
> >
> > syz_emit_ethernet(0x86, &(0x7f0000000000)={@...al, @empty=[0x2],
> > @void, {@...4={0x800, @udp={{0x5, 0x4, 0x0, 0x0, 0x78, 0x0, 0x0, 0x0,
> > 0x11, 0x0, @empty, @empty}, {0x0, 0x1b59, 0x64, 0x0,
> > @wg=@...ponse={0x5, 0x0, 0x0, "020000010865390406030500000000010900",
> > "9384bbeb3018ad591b661fe808b21b77",
> > {"694c875dfb1be5d2a0057a62022a1564",
> > "a329d3a73b8268129e5fa4316a5d8c69"}}}}}}}, 0x0)
> > mkdirat(0xffffffffffffff9c, &(0x7f0000000000)='./file0\x00', 0x0)
> > mount(0x0, &(0x7f0000000080)='./file0\x00',
> > &(0x7f0000000040)='cgroup2\x00', 0x0, 0x0)
> > r0 = openat$cgroup_root(0xffffffffffffff9c, &(0x7f0000000000), 0x200002, 0x0)
> > r1 = bpf$PROG_LOAD(0x5, &(0x7f0000000080)={0x9, 0x4,
> > &(0x7f0000000000)=@...med={{}, [@alu={0x8000000201a7f19, 0x0, 0x6,
> > 0x2, 0x1}]}, &(0x7f0000000100)='GPL\x00', 0x0, 0x0, 0x0, 0x0, 0x0, [],
> > 0x0, 0x0, 0xffffffffffffffff, 0x8, 0x0, 0x0, 0x10, 0x0}, 0x70)
> > bpf$BPF_LINK_CREATE(0x1c, &(0x7f0000000100)={r1, r0, 0x2}, 0x10)
> >
>
> The only place where BPF link-related code is bumping refcount for
> net_device is in bpf_xdp_link_attach(), but both success and failure
> code paths always do dev_put() in the end. bpf_link itself has a
> pointer on net_device, but it's protected by rtnl_lock() only, no
> refcnt associated with it. So I don't see how bpf_link can cause this.
> I also couldn't reproduce this locally, using the provided C
> reproducer.
I was able to reproduce this in qemu the first time.
Powered by blists - more mailing lists