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

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.