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

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

[David Woodhouse]

[-- 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 --]

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

[David Woodhouse]

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

On Fri, 2026-10-30 at 16:38 +0000, David Woodhouse wrote:
> 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>

Ping?

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

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

[Jason A. Donenfeld]

On Fri, Oct 30, 2026 at 04:38:06PM +0000, David Woodhouse wrote:
> 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.

Hmm... How did you choose __ip_dev_find() over, say,
inet_lookup_ifaddr_rcu(), which is structurally more similar to
ipv6_chk_addr()?

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

[David Woodhouse]

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

On Tue, 2026-11-10 at 17:12 +0100, Jason A. Donenfeld wrote:
> 
> Hmm... How did you choose __ip_dev_find() over, say,
> inet_lookup_ifaddr_rcu(), which is structurally more similar to
> ipv6_chk_addr()?

__ip_dev_find() is what's exported to modules. It internally takes the
RCU lock and calls inet_lookup_ifaddr_rcu(). It also falls back to a 
RT_TABLE_LOCAL lookup, which I think is the right thing here too.

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