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
panic_grsec_disabled.config.gz
Description: application/gzip
panic_grsec_disabled.dmesg.gz
Description: application/gzip
_______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
