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

["Jason A. Donenfeld" <Jason@zx2c4.com>]

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()?