Re: [PATCH net v2 2/4] ipv4: udp: Create exceptions before socket matching

[Ido Schimmel <idosch@nvidia.com>]

On Fri, Aug 28, 2026 at 10:23:42PM +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 only created 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 before
> trying to find a matching socket. Do that by calling ipv4_update_pmtu()
> and ipv4_redirect(), the helpers used when the quoted packet did not
> originate from a socket.
> 
> This means that guesses (right or wrong) from an off-path attacker will
> always result in a FNHE being created or updated in the cache that the
> attacker can observe.
> 
> Pass an oif of 0, in a similar fashion to icmp_err(). This is also the
> oif used by the socket path for sockets that are not bound to a device.
> 
> 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 note that in the good case (matched socket) the above scheme comes
> at the cost of an extra route lookup, as the no socket helpers perform
> their own lookup before the one performed by ipv4_sk_update_pmtu() /
> ipv4_sk_redirect(). When the two resolve to different nexthops, it also
> results in two exceptions being created for the same destination IP. One
> in the FNHE cache of the nexthop resolved by the no socket helpers and
> another in the FNHE cache of the nexthop used by the socket.

tl;dr - I don't think anything needs to change here following the
Sashiko feedback [1].

"Does the hard-coded oif of 0 leave the oracle intact for device-bound,
VRF-bound and policy-routed sockets?"

No. An attacker needs to be able to populate the exception cache of the
nexthop used by the socket. If this cache is not reachable via the
no-socket helpers (e.g., because the socket is VRF bound), then the side
channel doesn't exist.

"This isn't a bug, but the new call runs before any socket is known, so the
per-socket opt-out that ipv4_sk_update_pmtu() honours is bypassed:

[...]

For a socket that set IP_PMTUDISC_INTERFACE or IP_PMTUDISC_OMIT, an ICMP
Frag Needed quoting its traffic previously created no PMTU state; now an
exception is installed on the nexthop resolved from the quoted packet.

The socket itself is unaffected, since ip_skb_dst_mtu() returns
min(dst_dev(dst)->mtu, IP_MAX_MTU) when ip_sk_use_pmtu(sk) is false, and
the same socket-less creation is already remotely reachable through
icmp_err() -> ipv4_update_pmtu(skb, net, info, 0, IPPROTO_ICMP). The
selftest patch in this series also asserts this as the intended behaviour
("a socket which disabled PMTU discovery using IP{,V6}_PMTUDISC_OMIT gets
the same exception as the other cases").

Could a sentence be added to the changelog noting that the per-socket
IP_PMTUDISC_INTERFACE / IP_PMTUDISC_OMIT opt-out no longer suppresses
exception creation?"

I don't see a reason to mention this. Exceptions are per-destination
constructs and they could have been created for destinations used by
IP_PMTUDISC_OMIT sockets even before this patch.

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