On 02/17/17 07:36, Jason A. Donenfeld wrote:
> Thanks very much for the excellent debugging output. I'll try to
> reproduce this as well on my systems.

I assume you have not been able to reproduce this issue.

> The stack trace does indicate that the OOPS is happening in padata,
> not in wireguard, so I wonder if this is some bug caused either by
> grsecurity or by something else that was then fixed, but since your
> kernel is a bit old (4.7.10) maybe the fix didn't make it. In either
> case, I'll try to reproduce on that kernel and on newer kernels and
> will get back to you.
>
> I presume you have most PaX options turned on?

Since this is on 4.7.10 (that is pre-4.9), this is not related to the
other bug recently reported.

I have disabled all grsecurity/PaX options in my kernel config
(attached) and was able to trigger the bug again. This is with WireGuard
commit f97b7e34bda436ac4572697a8770837eec7470b6 and debugging enabled.
Again attached is the dmesg.

I used the same SSH cat /dev/zero | dd of=/dev/null as before. This time
I got "192656101376 bytes (193 GB, 179 GiB) copied, 41643 s, 4.6 MB/s"
before the connection was broken.

Interestingly, when the firewall came back up, I again had the issue
where devices were continuing to handshake, but no data went through
(and I could confirm this with the wireguard debug output in dmesg).

I was unable to reproduce this issue with a spare laptop (ThinkPad
X220), even after leaving it running for about three days. Since the
router has a rather weak Atom CPU (http://ark.intel.com/products/78866),
I suspect maybe a race condition due to the high load might be involved?

Is there anything else I can do to debug this? Enable some kernel
debugging option? Try a vanilla kernel? Try a newer kernel?

> Thanks, Jason

Thanks,
Samuel Holland