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

On Fri, Jul 24, 2026 at 3:42 PM Jakub Kicinski [off-list ref] wrote:

On Fri, 24 Jul 2026 07:29:01 +0000 Eric Dumazet wrote:

quoted

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.

I have no idea really :/

vng --cwd tools/testing/selftests/net -p 4 -r ./arch/x86/boot/bzImage
-- ./fib_tests.sh

 All tests are [ OK ] for me.

Tests passed: 257
Tests failed:   0

Note that my change in ip6_forward() does not early-return, unless I
am mistaken.

diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 368e4fa3b43ca2a96f53fa4f3bc14fd6832c346f..2c44e5ed617167ce060c265052cd40449fdab69f

100644

--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c

@@ -641,7 +641,7 @@ int ip6_forward(struct sk_buff *skb)
                /* Limit redirects both by destination (here)
                   and by source (inside ndisc_send_redirect)
                 */
-               if (inet_peer_xrlim_allow(peer, 1*HZ))
+               if (peer && inet_peer_xrlim_allow(peer, 1*HZ))
                        ndisc_send_redirect(skb, target);
                rcu_read_unlock();
        } else {