lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3e523601-88b5-4aba-bf90-916b87d73555@kernel.org>
Date: Mon, 1 Sep 2025 20:37:05 -0600
From: David Ahern <dsahern@...nel.org>
To: Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 edumazet@...gle.com, horms@...nel.org, paul@...l-moore.com,
 petrm@...dia.com, linux-security-module@...r.kernel.org
Subject: Re: [PATCH net-next 3/8] ipv4: icmp: Fix source IP derivation in
 presence of VRFs

On 9/1/25 2:30 AM, Ido Schimmel wrote:
> 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@...dia.com>
> Reported-by: Rajkumar Srinivasan <rajsrinivasa@...dia.com>
> Reviewed-by: Petr Machata <petrm@...dia.com>
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
>  net/ipv4/icmp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Reviewed-by: David Ahern <dsahern@...nel.org>



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ