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

[David Woodhouse]

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

Ping?

Attachment: smime.p7s
Description: S/MIME cryptographic signature