[PATCH net] udp_tunnel: don't treat IPv4 sockets bound to an address as wildcard

[PATCH net] udp_tunnel: don't treat IPv4 sockets bound to an address as wildcard

[Antonio Quartulli]

With IPv6 enabled, sk_saddr_any() checks sk_v6_rcv_saddr also for
AF_INET sockets, where it is always zero. An IPv4 tunnel socket bound to
a specific address (e.g. fou or geneve with "local") ends up in the GRO
lookup fast path, although another socket may bind the same port on a
different address: GRO then hands that socket's packets to the tunnel's
gro_receive.

Check the IPv6 address only for AF_INET6 sockets.

Fixes: a36283e2b683 ("udp_tunnel: create a fastpath GRO lookup.")
Signed-off-by: Antonio Quartulli <antonio@mandelbit.com>
---
 net/ipv4/udp_tunnel_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c
index a128fe85620d..29581c94fdcf 100644
--- a/net/ipv4/udp_tunnel_core.c
+++ b/net/ipv4/udp_tunnel_core.c
@@ -62,10 +62,10 @@ EXPORT_SYMBOL(udp_sock_create4);
 static bool sk_saddr_any(struct sock *sk)
 {
 #if IS_ENABLED(CONFIG_IPV6)
-	return ipv6_addr_any(&sk->sk_v6_rcv_saddr);
-#else
-	return !sk->sk_rcv_saddr;
+	if (sk->sk_family == AF_INET6)
+		return ipv6_addr_any(&sk->sk_v6_rcv_saddr);
 #endif
+	return !sk->sk_rcv_saddr;
 }
 
 void setup_udp_tunnel_sock(struct net *net, struct sock *sk,
-- 
2.56.0

Re: [PATCH net] udp_tunnel: don't treat IPv4 sockets bound to an address as wildcard

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] udp_tunnel: don't treat IPv4 sockets bound to an address as wildcard

[Antonio Quartulli]

Hi there, humans and not! :-)

On 10/11/2026 12:36, netdev-bot+sinfo@kernel.org wrote:
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>   - How the issue was discovered, e.g. hit in production, hit during
>     development, syzbot report, manual code inspection, LLM or static
>     analysis tool scan.
> 
>   - Whether the issue was actually triggered, or is only theoretical
>     (e.g. found by code inspection). If it was triggered please include
>     the symptoms, like the stack trace or error messages.
> 

The issue was discovered by an AI coding assistant during code
inspection, while working on extending the UDP tunnel GRO lookup fast
path (more on this in the coming days..).

It was then triggered on an unmodified kernel (current net): a UDP
socket loses the datagrams sent to its port when an IPv4 fou socket
bound to another address uses the same port:

   ip netns add rx; ip netns add tx
   ip link add vtx netns tx type veth peer name vrx netns rx
   ip -n rx addr add 10.9.0.1/24 dev vrx; ip -n rx addr add 10.9.0.2/24 
dev vrx
   ip -n tx addr add 10.9.0.3/24 dev vtx
   ip -n rx link set vrx up; ip -n tx link set vtx up
   ip netns exec rx ethtool -K vrx gro on
   ip netns exec tx ethtool -K vtx tso off tx-udp-segmentation off
   ip -n rx fou add port 5556 ipproto 4 local 10.9.0.1

   # then....
   # rx: UDP socket bound to 10.9.0.2:5556 by some $software;
   # tx: one UDP_SEGMENT send of 32 datagrams of 1040 bytes to it,
   # each a valid IPv4/TCP segment of one flow (quite unusual..but possible)

Without the patch the bound socket receives none of the 32 datagrams:
the GRO lookup fast path hands them to fou's gro_receive, which merges
them as one inner TCP flow, and the aggregate is then completed for the
plain socket.

Datagrams of the same size that don't look like IPv4 arrive
intact. With the patch all 32 arrive. (Tracing the GRO path with debug
prints in a modified kernel confirmed that sequence.)

The fix was tested:
* with that reproducer
* with a check that fou on the IPv4 wildcard, fou bound to an IPv6 
address and both vxlan sockets (IPv4 and IPv6-only) are still registered 
for the fast path as before (using a debug print on registration)
* with the ovpn selftests on a debug kernel (lockdep, KASAN).

[If needed, the reproducer script is available on request]

All in all, not a critical bug, but still something worth fixing, IMHO.

Regards,


-- 
Antonio Quartulli

CEO and Co-Founder
Mandelbit Srl
https://www.mandelbit.com