[PATCH] wireguard: socket: fix sticky source address on p2p

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2667 bytes --]

From: David Woodhouse <dwmw@amazon.co.uk>

WireGuard attempts to reply from the address to which the original
packet was sent, caching it in endpoint->src4 and validating it before
each use with inet_confirm_addr(..., RT_SCOPE_HOST).

For Legacy IP that validation always fails for an address on a point-
to-point interface, because confirm_addr_indev() insists on
inet_ifa_match(), which compares against ifa_address — the *peer*
address on a p2p link — under a /32 mask. The local address is never
within that "subnet", so a perfectly valid source address is discarded
and send4() falls back to kernel source address selection.

For peers on the far side of the p2p link, the fallback happens to
select the same address and nobody notices. But when a peer on a local
LAN sends to the p2p address (e.g. my OpenWrt box listening on its
external PPPoE address), the reply is sent from the LAN interface's own
address instead. A stateful firewall on the peer then drops the reply
as unrelated to the flow it originated, and the handshake never
completes.

inet_confirm_addr() is an ARP helper answering "do I have an address
on the same subnet as this"; what send4() wants to ask is only "is
this still a local address". Use __ip_dev_find() for that, matching
what send6() already does with ipv6_chk_addr(). IPv6 does not have
this problem.

Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
Reproducer: https://david.woodhou.se/wg-ptp-test.sh

Creates a netns pair, server with a dummy iface carrying p2p
addressing (ip addr add 10.9.9.1 peer 10.9.9.2/32), client sending
to 10.9.9.1 over a veth "LAN". Before: handshake responses come from
the veth address. After: from 10.9.9.1. The IPv6 twin of the same
test passes unpatched.

I think drivers/net/ovpn/udp.c has the same issue and will need the
same fix, but I haven't tested that.

 drivers/net/wireguard/socket.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireguard/socket.c b/drivers/net/wireguard/socket.c
index 0028ef17dc71..a954ba0b4467 100644
--- a/drivers/net/wireguard/socket.c
+++ b/drivers/net/wireguard/socket.c
@@ -50,8 +50,8 @@ static int send4(struct wg_device *wg, struct sk_buff *skb,
 
 	if (!rt) {
 		security_sk_classify_flow(sock, flowi4_to_flowi_common(&fl));
-		if (unlikely(!inet_confirm_addr(sock_net(sock), NULL, 0,
-						fl.saddr, RT_SCOPE_HOST))) {
+		if (unlikely(fl.saddr &&
+			     !__ip_dev_find(sock_net(sock), fl.saddr, false))) {
 			endpoint->src4.s_addr = 0;
 			endpoint->src_if4 = 0;
 			fl.saddr = 0;

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]