Re: [PATCH net 2/4] ipv4: udp: Create exceptions when socket matching failed

[Ido Schimmel <idosch@nvidia.com>]

On Wed, Aug 26, 2026 at 05:37:33PM +0300, Ido Schimmel wrote:
> Currently, when ICMP Fragmentation Needed and Redirect Message packets
> are locally delivered and quote a UDP packet, a FIB nexthop exception
> (FNHE) is created only if the kernel can match the UDP packet to an
> existing socket.
> 
> This behavior allows off-path attackers to conduct a side-channel attack
> on the FNHE cache in order to discover the ephemeral port used by a
> connected UDP socket.
> 
> Commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in
> fnhe_hashfun()") and commit 67d6d681e15b ("ipv4: make exception cache
> less predictible") tried to mitigate such attacks by making it harder
> for attackers to discover hash collisions in the FNHE cache and by
> randomizing the number of exceptions a hash bucket can hold,
> respectively. Unfortunately, both of the mitigations can be bypassed.
> 
> Instead, mitigate such attacks by always creating a FNHE, even if socket
> matching failed. Do that by calling ipv4_update_pmtu() and
> ipv4_redirect(), the helpers used when the quoted packet did not
> originate from a socket. The resulting FNHE is indistinguishable from
> the one created when socket matching succeeded, both in terms of cache
> occupancy and in terms of its contents.
> 
> Pass an oif of 0, in a similar fashion to icmp_err().
> 
> Note that this does not allow attackers to create FNHEs that they could
> not create before, as both helpers can already be reached with little to
> no validation. For example, by sending an ICMP error that quotes an ICMP
> Echo Reply or one that quotes a UDP source port that matches a wildcard
> socket.
> 
> Also create a FNHE when a socket does not wish to accept PMTU updates
> (e.g., by setting 'IP_PMTUDISC_OMIT'). Otherwise, the fact that a FNHE
> was not created can indicate to an off-path attacker that a socket
> exists. This applies to all ipv4_sk_update_pmtu() callers, so ping and
> raw sockets that decline PMTU updates will now create a FNHE as well.
> Such sockets are not affected by it, as ip_skb_dst_mtu() uses the MTU of
> the device for them.

tl;dr - I will send v2 that calls udp_err_no_sk() unconditionally and
remove the net/ipv4/route.c hunk. Same for patch 3. It means two route
lookups in the good case (matched socket), but I think we can live with
that.

Two comments from Sashiko [1]:

1. "Inverted signal". This is correct and it's something I considered,
but it's impractical:

a. Without the patch, a wrong guess is cheap and an attacker can keep
scanning. With the patch, each wrong guess requires the attacker to
repeat the setup phase which brings the cache to a state where a wrong /
correct guess is indicative of the presence of a socket. This is
time-consuming and therefore impractical given that the sockets of
interest are short lived.

b. It requires "non-default routing attributes" which is uncommon.

We can completely eliminate the "inverted signal" by calling
udp_err_no_sk() unconditionally.

2. The comment regarding fou/gue seems valid, but it requires fou to be
loaded which is again uncommon. Can be fixed by [2] or by simply calling
udp_err_no_sk() unconditionally.

[1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826143735.1819315-1-idosch%40nvidia.com

[2]
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 6981526bd59c..c32c416601da 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -941,8 +941,10 @@ int udp_err(struct sk_buff *skb, u32 info)
 		/* No socket for error: try tunnels before discarding */
 		if (static_branch_unlikely(&udp_encap_needed_key)) {
 			sk = __udp4_lib_err_encap(net, iph, uh, sk, skb, info);
-			if (!sk)
+			if (!sk) {
+				udp_err_no_sk(net, skb, type, code, info);
 				return 0;
+			}
 		} else
 			sk = ERR_PTR(-ENOENT);