Re: [PATCH net-next v1] icmp: fix ip_rt_bug race in icmp_route_lookup reverse path

February 4, 2026 at 24:24, "David Ahern" <dsahern@kernel.org mailto:dsahern@kernel.org?to=%22David%20Ahern%22%20%3Cdsahern%40kernel.org%3E > wrote:

On 2/3/26 3:41 AM, Paolo Abeni wrote:

quoted

On 1/28/26 10:05 AM, Jiayuan Chen wrote:

quoted

diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
 index 19c9c838967f..dc9dcc799824 100644
 --- a/net/ipv4/icmp.c
 +++ b/net/ipv4/icmp.c
 @@ -559,6 +559,23 @@ static struct rtable *icmp_route_lookup(struct net *net, struct flowi4 *fl4,
 /* steal dst entry from skb_in, don't drop refcnt */
 skb_dstref_steal(skb_in);
 skb_dstref_restore(skb_in, orefdst);
 +
 + /*
 + * At this point, fl4_dec.daddr should NOT be local (we
 + * checked fl4_dec.saddr above). However, a race condition
 + * may occur if the address is added to the interface
 + * concurrently. In that case, ip_route_input() returns a
 + * LOCAL route with dst.output=ip_rt_bug, which must not
 + * be used for output.
 + */
 + if (!err && rt2 && rt2->rt_type == RTN_LOCAL) {
 + net_warn_ratelimited("%s: detected local route for %pI4 "
 + "during ICMP error handling (src %pI4), "
 + "possible address race\n",
 + __func__, &fl4_dec.daddr, &fl4_dec.saddr);

 
 The fix looks correct to me, but this patch should target the 'net' tree
 and the above warning message is a bit off: the text string should not
 be broken to fit the 80 chars limit - it need to be greepable - it's
 probably better to not include the function name.
 
 /P

Does the message even provide value? There is nothing a user can do
about it.

Hi Paolo, David,

Thanks for the review.

Paolo, I'll fix it in newer version.

Regarding David's question about whether the message provides value:
I think it could still be useful for debugging. If a user's configuration
change causes ICMP packets to be silently dropped, there's currently no counter
or indication of what happened. Adding a dedicated counter for this rare race
condition seems overkill, so a rate-limited warning at least gives some visibility
into the failure.

That said, I'm open to dropping the message entirely if you both think silent handling
is preferred. Let me know and I'll send a new version either way.

Thanks,
Jiayuan