Re: [PATCH net] net: do not send ICMP/NDISC Redirects when peer allocation fails

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 24 Jul 2026 07:29:01 +0000 Eric Dumazet wrote:
> When inet_getpeer_v4() or inet_getpeer_v6() fails to allocate a peer entry
> under memory pressure or tree size caps, redirect handlers previously fell
> back to sending un-rate-limited ICMP/NDISC Redirect messages.
> 
> In IPv4, ip_rt_send_redirect() called icmp_send() directly when peer == NULL.
> In IPv6, ip6_forward() and ndisc_send_redirect() passed a NULL peer into
> inet_peer_xrlim_allow(), which returned true when peer == NULL.
> 
> Because ICMP/NDISC Redirects are not part of the default global rate limit
> mask (sysctl_icmp_ratemask), sending redirects when peer == NULL creates
> an un-rate-limited ICMP packet storm.
> 
> Fix this by failing closed in ip_rt_send_redirect(), ip6_forward(), and
> ndisc_send_redirect() when peer is NULL.

Bot says:

The following selftest regression was observed after applying this patch:

  Test:   tools/testing/selftests/net/fib_tests.sh
  Result: FAIL (reproduced on retry)
  Runner: vmksft-net (x86-64, kernel selftests VM)

The test passes all sections up through the IPv6 route garbage-collection
tests and then fails with:

  Error while performing Neighbor Discovery for the Destination Address
  Error while learning Source Address and Next Hop
  not ok 1 selftests: net: fib_tests.sh # exit=1

This happens during the multipath balance/list tests that follow fib6_gc_test.
Those tests probe IPv6 multipath routes using `ip route get`, which requires
NDP to resolve nexthop addresses through a forwarding path.

The new early-return in ip6_forward() when inet_getpeer_v6() returns NULL
(peer allocation failure, added by this patch) can drop IPv6 packets that
would previously have been forwarded (and a redirect sent).  In the test
environment, freshly-created network namespaces may encounter peer-tree
allocation pressure after the many namespace allocations in earlier test
sections, causing this path to be exercised unexpectedly and silently
dropping NDP probes, which causes `ip route get` to return EHOSTUNREACH.

Could you investigate whether the early-return in ip6_forward() for the
NULL-peer case is too aggressive?  In particular, if the goal is only to
suppress the redirect (which is correct), dropping the packet entirely on
a NULL peer may be undesirable — the right approach might be to continue
forwarding the packet but skip the redirect logic when peer is NULL.