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: <20250910083229.GK341237@unreal>
Date: Wed, 10 Sep 2025 11:32:29 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Edward Srouji <edwards@...dia.com>
Cc: jgg@...pe.ca, linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
	parav@...dia.com, cratiu@...dia.com, vdumitrescu@...dia.com,
	kuba@...nel.org, tariqt@...dia.com, mbloch@...dia.com,
	gal@...dia.com
Subject: Re: [PATCH 2/4] RDMA/core: Resolve MAC of next-hop device without
 ARP support

On Sun, Sep 07, 2025 at 07:08:31PM +0300, Edward Srouji wrote:
> From: Parav Pandit <parav@...dia.com>
> 
> Currently, if the next-hop netdevice does not support ARP resolution,
> the destination MAC address is silently set to zero without reporting
> an error. 

Not an expert here, but from my understanding this is right behavior.
IFF_NOARP means "leave" MAC address as is (zero).

> This leads to incorrect behavior and may result in packet transmission failures.
> 
> Fix this by deferring MAC resolution to the IP stack via neighbour
> lookup, allowing proper resolution or error reporting as appropriate.

What is the difference here? For IPv4, neighbour lookup is ARP, no?

> 
> Fixes: 7025fcd36bd6 ("IB: address translation to map IP toIB addresses (GIDs)")
> Signed-off-by: Parav Pandit <parav@...dia.com>
> Reviewed-by: Vlad Dumitrescu <vdumitrescu@...dia.com>
> Signed-off-by: Edward Srouji <edwards@...dia.com>
> ---
>  drivers/infiniband/core/addr.c | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> index 594e7ee335f7..ca86c482662f 100644
> --- a/drivers/infiniband/core/addr.c
> +++ b/drivers/infiniband/core/addr.c
> @@ -454,14 +454,10 @@ static int addr_resolve_neigh(const struct dst_entry *dst,
>  {
>  	int ret = 0;
>  
> -	if (ndev_flags & IFF_LOOPBACK) {
> +	if (ndev_flags & IFF_LOOPBACK)
>  		memcpy(addr->dst_dev_addr, addr->src_dev_addr, MAX_ADDR_LEN);
> -	} else {
> -		if (!(ndev_flags & IFF_NOARP)) {
> -			/* If the device doesn't do ARP internally */
> -			ret = fetch_ha(dst, addr, dst_in, seq);
> -		}
> -	}
> +	else
> +		ret = fetch_ha(dst, addr, dst_in, seq);
>  	return ret;
>  }
>  
> -- 
> 2.21.3
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ