On Thu, Feb 20, 2020 at 5:34 PM Jason A. Donenfeld <[email protected]> wrote: > > Hi Dmitry, > > On Thu, Feb 20, 2020 at 5:14 PM Dmitry Vyukov <[email protected]> wrote: > > I got some coverage in wg_netdevice_notification: > > https://imgur.com/a/1sJZKtp > > > > Or you mean the parts that are still red? > > Yes, it's the red parts that interest me. Intermixing those with > various wireguard-specific netlink calls and setting devices up and > down and putting traffic through those sockets, in weird ways, could > dig up bugs. > > > I think theoretically these parts should be reachable too because > > syzkaller can do unshare and obtain net ns fd's. > > > > It's quite hard to test because it just crashes all the time on known bugs. > > So maybe the most profitable way to get more coverage throughout the > > networking subsystem now is to fix the top layer of crashers ;) > > Ahhh, interesting, so the issue is that syzkaller is finding too many > other networking stack bugs before it gets to being able to play with > wireguard. Shucks.
If it's aimed only at, say, wireguard netlink interface, then it's not distracted by bugs in other parts. But as you add some ipv4/6 tcp/udp sockets, more netlink to change these net namespaces, namespaces related syscalls, packet injection, etc, in the end it covers quite a significant part of kernel. You know how fuzzing works, right. You really need to fix the current layer of bugs to get to the next one. And we accumulated 600+ open bugs. It still finds some new ones, but I guess these are really primitive ones (as compared to its full bug finding potential). _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
