summaryrefslogtreecommitdiff
path: root/security/inode.c
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2020-05-07 00:33:03 +0300
committerDavid S. Miller <davem@davemloft.net>2020-05-07 06:03:47 +0300
commitb673e24aad36981f327a6570412ffa7754de8911 (patch)
tree7df3be82da0cc598286970cddbb764ae46fc0f4c /security/inode.c
parenta0fd7cc87a018df1a17f9d3f0bd994c1f22c6b34 (diff)
downloadlinux-b673e24aad36981f327a6570412ffa7754de8911.tar.xz
wireguard: socket: remove errant restriction on looping to self
It's already possible to create two different interfaces and loop packets between them. This has always been possible with tunnels in the kernel, and isn't specific to wireguard. Therefore, the networking stack already needs to deal with that. At the very least, the packet winds up exceeding the MTU and is discarded at that point. So, since this is already something that happens, there's no need to forbid the not very exceptional case of routing a packet back to the same interface; this loop is no different than others, and we shouldn't special case it, but rather rely on generic handling of loops in general. This also makes it easier to do interesting things with wireguard such as onion routing. At the same time, we add a selftest for this, ensuring that both onion routing works and infinite routing loops do not crash the kernel. We also add a test case for wireguard interfaces nesting packets and sending traffic between each other, as well as the loop in this case too. We make sure to send some throughput-heavy traffic for this use case, to stress out any possible recursion issues with the locks around workqueues. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'security/inode.c')
0 files changed, 0 insertions, 0 deletions