public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: <netdev@vger.kernel.org>
Cc: <davem@davemloft.net>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<edumazet@google.com>, <horms@kernel.org>, <paul@paul-moore.com>,
	<dsahern@kernel.org>, <petrm@nvidia.com>,
	<linux-security-module@vger.kernel.org>,
	Ido Schimmel <idosch@nvidia.com>
Subject: [PATCH net-next v2 3/8] ipv4: icmp: Fix source IP derivation in presence of VRFs
Date: Mon, 8 Sep 2025 10:32:33 +0300	[thread overview]
Message-ID: <20250908073238.119240-4-idosch@nvidia.com> (raw)
In-Reply-To: <20250908073238.119240-1-idosch@nvidia.com>

When the "icmp_errors_use_inbound_ifaddr" sysctl is enabled, the source
IP of ICMP error messages should be the "primary address of the
interface that received the packet that caused the icmp error".

The IPv4 ICMP code determines this interface using inet_iif() which in
the input path translates to skb->skb_iif. If the interface that
received the packet is a VRF port, skb->skb_iif will contain the ifindex
of the VRF device and not that of the receiving interface. This is
because in the input path the VRF driver overrides skb->skb_iif with the
ifindex of the VRF device itself (see vrf_ip_rcv()).

As such, the source IP that will be chosen for the ICMP error message is
either an address assigned to the VRF device itself (if present) or an
address assigned to some VRF port, not necessarily the input or output
interface.

This behavior is especially problematic when the error messages are
"Time Exceeded" messages as it means that utilities like traceroute will
show an incorrect packet path.

Solve this by determining the input interface based on the iif field in
the control block, if present. This field is set in the input path to
skb->skb_iif and is not later overridden by the VRF driver, unlike
skb->skb_iif.

This behavior is consistent with the IPv6 counterpart that already uses
the iif from the control block.

Reported-by: Andy Roulin <aroulin@nvidia.com>
Reported-by: Rajkumar Srinivasan <rajsrinivasa@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 net/ipv4/icmp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 59fd0e1993a6..1b7fb5d935ed 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -710,7 +710,8 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info,
 		rcu_read_lock();
 		if (rt_is_input_route(rt) &&
 		    READ_ONCE(net->ipv4.sysctl_icmp_errors_use_inbound_ifaddr))
-			dev = dev_get_by_index_rcu(net, inet_iif(skb_in));
+			dev = dev_get_by_index_rcu(net, parm->iif ? parm->iif :
+						   inet_iif(skb_in));
 
 		if (dev)
 			saddr = inet_select_addr(dev, iph->saddr,
-- 
2.51.0


  parent reply	other threads:[~2025-09-08  7:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-08  7:32 [PATCH net-next v2 0/8] ipv4: icmp: Fix source IP derivation in presence of VRFs Ido Schimmel
2025-09-08  7:32 ` [PATCH net-next v2 1/8] ipv4: cipso: Simplify IP options handling in cipso_v4_error() Ido Schimmel
2025-09-08  7:51   ` Eric Dumazet
2025-09-08  7:32 ` [PATCH net-next v2 2/8] ipv4: icmp: Pass IPv4 control block structure as an argument to __icmp_send() Ido Schimmel
2025-09-08  7:55   ` Eric Dumazet
2025-09-08  7:32 ` Ido Schimmel [this message]
2025-09-08  7:32 ` [PATCH net-next v2 4/8] selftests: traceroute: Return correct value on failure Ido Schimmel
2025-09-08  7:32 ` [PATCH net-next v2 5/8] selftests: traceroute: Use require_command() Ido Schimmel
2025-09-08  7:32 ` [PATCH net-next v2 6/8] selftests: traceroute: Reword comment Ido Schimmel
2025-09-08  7:32 ` [PATCH net-next v2 7/8] selftests: traceroute: Test traceroute with different source IPs Ido Schimmel
2025-09-08  7:32 ` [PATCH net-next v2 8/8] selftests: traceroute: Add VRF tests Ido Schimmel
2025-09-11 10:40 ` [PATCH net-next v2 0/8] ipv4: icmp: Fix source IP derivation in presence of VRFs patchwork-bot+netdevbpf

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=20250908073238.119240-4-idosch@nvidia.com \
    --to=idosch@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=petrm@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox