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

[Antonio Quartulli <antonio@mandelbit.com>]

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