On Mon, Feb 17, 2020 at 12:44 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > Observation: > > It seems to be starting to synthesize packets sent to the wireguard > socket. These aren't the proper handshake packets generated internally > by that triangle commit, but rather ones that syzkaller creates > itself. That's why we have coverage on wg_receive, which otherwise > wouldn't be called from a userspace process, since syzbot is sending > its own packets to that function. > > However, the packets it generates aren't getting very far, failing all > of the tests in validate_header_len. None of those checks are at all > cryptographic, which means it should be able to hit those eventually. > Anything we should be doing to help it out? After it gets past that > check, it'll wind up in the handshake queue or the data queue, and > then (in theory) it should be rejected on a cryptographic basis. But > maybe syzbot will figure out how to crash it instead :-P.
Looking into this. Found the program that gives wg_receive coverage: r0 = openat$tun(0xffffffffffffff9c, &(0x7f0000000080)='/dev/net/tun\x00', 0x88002, 0x0) ioctl$TUNSETIFF(r0, 0x400454ca, &(0x7f00000000c0)={'syzkaller1\x00', 0x420000015001}) r1 = socket$netlink(0x10, 0x3, 0x0) ioctl$sock_inet_SIOCSIFADDR(r1, 0x8914, &(0x7f0000000140)={'syzkaller1\x00', {0x7, 0x0, @empty}}) write$tun(r0, &(0x7f00000002c0)={@void, @val, @ipv4=@udp={{0x5, 0x4, 0x0, 0x0, 0x1c, 0x0, 0x0, 0x0, 0x11, 0x0, @remote, @broadcast}, {0x0, 0x4e21, 0x8}}}, 0x26) Checked that doing SIOCSIFADDR is also required, otherwise the packet does not reach wg_receive. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard