From: Ido Schimmel <idosch@nvidia.com>
To: Dong Chenchen <dongchenchen2@huawei.com>
Cc: dsahern@kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
herbert@gondor.apana.org.au, netdev@vger.kernel.org,
zhangchangzhong@huawei.com
Subject: Re: [PATCH net v3] ipv4: icmp: reject RTN_UNREACHABLE input routes in icmp_route_lookup
Date: Wed, 26 Aug 2026 18:40:17 +0300 [thread overview]
Message-ID: <20260826154017.GA1834664@shredder> (raw)
In-Reply-To: <20260825094523.1461020-1-dongchenchen2@huawei.com>
On Tue, Aug 25, 2026 at 05:45:23PM +0800, Dong Chenchen wrote:
> When the forward output route cannot be used in icmp_route_lookup(),
> it enters the "reverse path" and calls ip_route_input() on fl4_dec.daddr,
> the original packet's source address.
>
> ip_route_input() only returns an error for truly invalid packets. For
> unreachable addresses it will succeed and return an input route whose
> dst.output is set to ip_rt_bug(). The existing check only rejects
> RTN_LOCAL routes, so the RTN_UNREACHABLE route types can still be returned
> and later used for output, syzkaller triggering a WARN_ON_ONCE()
> in ip_rt_bug() as bellow:
>
> ------------[ cut here ]------------
> WARNING: net/ipv4/route.c:1273 at ip_rt_bug+0x14/0x20
> RIP: 0010:ip_rt_bug+0x14/0x20
> Call Trace:
> ip_push_pending_frames+0xfa/0x100
> __icmp_send+0x905/0xf10
> ip_options_compile+0xc0/0xd0
> ip_rcv_finish_core+0x321/0xae0
> ip_rcv+0x1de/0x260
> __netif_receive_skb_one_core+0x11a/0x130
> netif_receive_skb+0x7b/0x260
> tun_get_user+0x11bf/0x1c10
> ------------[ cut here ]------------
>
> Reject input route that is RTN_UNREACHABLE to fix it.
Nit: Also mention that the warning is only printed for RTN_LOCAL, as
RTN_UNREACHABLE is not the result of a race condition.
>
> Fixes: 8b7817f3a959 ("[IPSEC]: Add ICMP host relookup support")
> Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
> ---
> v2:
> - RTN_UNICAST judgement will reject bforward packet. Only reject RTN_UNREACHABLE
> v3:
> - Modify the comments to make them more accurate.
> - RTN_UNREACHABLE dont need warn log.
> ---
> net/ipv4/icmp.c | 17 ++++++++---------
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> index 0caedfc7ca92..7350f0380be1 100644
> --- a/net/ipv4/icmp.c
> +++ b/net/ipv4/icmp.c
> @@ -581,16 +581,15 @@ static struct rtable *icmp_route_lookup(struct net *net, struct flowi4 *fl4,
> 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.
> + * At this point, fl4_dec.daddr should NOT be local (the
> + * address can be added to the interface concurrently) or unroutable.
> + * In that case, ip_route_input() returns a LOCAL or UNREACHABLE
> + * route with dst.output=ip_rt_bug, which must not be used for output.
> */
The code is fine, but the comment is a bit misleading (the "should NOT"
part is only correct for "local"). I find this clearer:
"
fl4_dec.daddr is not expected to be local here, but it can be added to
an interface concurrently, in which case ip_route_input() returns a
LOCAL route. It can also fail to build a forwarding route towards
fl4_dec.daddr, for example, when forwarding is disabled, and return an
UNREACHABLE route. Both cases will result in a route with
dst.output=ip_rt_bug, which must not be used for output.
"
Thanks!
next prev parent reply other threads:[~2026-08-26 15:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 9:45 [PATCH net v3] ipv4: icmp: reject RTN_UNREACHABLE input routes in icmp_route_lookup Dong Chenchen
2026-08-25 12:09 ` Jiayuan Chen
2026-08-26 15:40 ` Ido Schimmel [this message]
2026-08-27 11:49 ` dongchenchen (A)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260826154017.GA1834664@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dongchenchen2@huawei.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=zhangchangzhong@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.