[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8d35f1aa44b4f228e104275a824adaacf0b36674.camel@sipsolutions.net>
Date: Thu, 20 Aug 2020 11:54:51 +0200
From: Johannes Berg <johannes@...solutions.net>
To: "Jason A. Donenfeld" <Jason@...c4.com>,
syzbot <syzbot+cc4c0f394e2611edba66@...kaller.appspotmail.com>
Cc: David Miller <davem@...emloft.net>,
Krzysztof Kozlowski <krzk@...nel.org>,
Jakub Kicinski <kuba@...nel.org>, kvalo@...eaurora.org,
leon@...nel.org, LKML <linux-kernel@...r.kernel.org>,
linux-kselftest@...r.kernel.org,
linux-wireless <linux-wireless@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>, Shuah Khan <shuah@...nel.org>,
syzkaller-bugs@...glegroups.com
Subject: Re: WARNING in __cfg80211_connect_result
On Thu, 2020-08-20 at 11:47 +0200, Jason A. Donenfeld wrote:
> On Wed, Aug 19, 2020 at 8:42 PM syzbot
> <syzbot+cc4c0f394e2611edba66@...kaller.appspotmail.com> wrote:
> > syzbot has bisected this issue to:
> >
> > commit e7096c131e5161fa3b8e52a650d7719d2857adfd
> > Author: Jason A. Donenfeld <Jason@...c4.com>
> > Date: Sun Dec 8 23:27:34 2019 +0000
> >
> > net: WireGuard secure network tunnel
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=175ad8b1900000
> > start commit: e3ec1e8c net: eliminate meaningless memcpy to data in pskb..
> > git tree: net-next
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=14dad8b1900000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10dad8b1900000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=3d400a47d1416652
> > dashboard link: https://syzkaller.appspot.com/bug?extid=cc4c0f394e2611edba66
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d9de91900000
> >
> > Reported-by: syzbot+cc4c0f394e2611edba66@...kaller.appspotmail.com
> > Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
>
> Having trouble linking this back to wireguard... Those oopses don't
> have anything to do with it either. Bisection error?
Probably the typical generic netlink issue - syzbot often hits the
generic netlink family by ID, rather than by name. So when it has a
kernel without WG a generic netlink family disappears, the later ones
get different IDs, and the issue no longer happens since the ID is now
no longer valid or hitting some completely different code path ...
johannes
Powered by blists - more mailing lists