All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: achender@kernel.org
Cc: Jakub Kicinski <kuba@kernel.org>,
	rds-devel@oss.oracle.com, edumazet@google.com,
	linux-rdma@vger.kernel.org, horms@kernel.org, pabeni@redhat.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH net v1 1/2] net/rds: Optimize rds_ib_laddr_check
Date: Mon,  6 Apr 2026 18:19:00 -0700	[thread overview]
Message-ID: <20260407011900.3596320-1-kuba@kernel.org> (raw)
In-Reply-To: <20260405041613.309958-2-achender@kernel.org>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net/rds: Optimize rds_ib_laddr_check

This patch optimizes rds_ib_laddr_check() to avoid excessive
rdma_bind_addr() calls by checking if an address has been used before.
It renames the original function to rds_ib_laddr_check_cm() and
introduces a new wrapper that first checks rds_ib_get_device() before
falling back to the CM-based check.

> diff --git a/net/rds/ib.c b/net/rds/ib.c
> index ac6affa33ce7..73e01984ee9a 100644
> --- a/net/rds/ib.c
> +++ b/net/rds/ib.c
> @@ -401,8 +401,8 @@ static void rds6_ib_ic_info(struct socket *sock, unsigned int len,
>   * allowed to influence which paths have priority.  We could call userspace
>   * asserting this policy "routing".
>   */
> -static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> -			      __u32 scope_id)
> +static int rds_ib_laddr_check_cm(struct net *net, const struct in6_addr *addr,
> +				 __u32 scope_id)
>  {
>  	int ret;
>  	struct rdma_cm_id *cm_id;

[ ... ]

> @@ -487,6 +487,20 @@ static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
>  	return ret;
>  }
>
> +static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> +			      __u32 scope_id)
> +{
> +	struct rds_ib_device *rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
> +
> +	if (rds_ibdev) {
> +		rds_ib_dev_put(rds_ibdev);
> +
> +		return 0;
> +	}
> +
> +	return rds_ib_laddr_check_cm(net, addr, scope_id);
> +}
> +

Can this code handle pure IPv6 addresses correctly? The function extracts
addr->s6_addr32[3] and passes it to rds_ib_get_device(), which looks up
devices by IPv4 address.

For IPv4-mapped IPv6 addresses, addr->s6_addr32[3] contains the IPv4
address. But for pure IPv6 addresses (when CONFIG_IPV6 is enabled),
addr->s6_addr32[3] contains the last 32 bits of the IPv6 address, which
could accidentally match a stored IPv4 address.

When this collision occurs, the function returns 0 (success) without
calling rds_ib_laddr_check_cm(), which performs the full validation
including rdma_bind_addr() and IPv6 link-local scope_id checks. This
means a pure IPv6 address could be incorrectly accepted as valid for IB
transport.

Should this be guarded with an ipv6_addr_v4mapped(addr) check? For
example:

    if (ipv6_addr_v4mapped(addr)) {
        rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
        ...
    }

The existing callers of rds_ib_get_device (rds_ib_get_mr,
rds_ib_update_ipaddr) operate in post-connection contexts where the
address type is already validated, but rds_ib_laddr_check is the
validation gate called during bind/transport-selection for any address
type.

>  static void rds_ib_unregister_client(void)
>  {
>  	ib_unregister_client(&rds_ib_client);

[ ... ]
-- 
pw-bot: cr

  reply	other threads:[~2026-04-07  1:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-05  4:16 [PATCH net v1 0/2] net/rds: Fix use-after-free in RDS/IB for non-init namespaces Allison Henderson
2026-04-05  4:16 ` [PATCH net v1 1/2] net/rds: Optimize rds_ib_laddr_check Allison Henderson
2026-04-07  1:19   ` Jakub Kicinski [this message]
2026-04-07  7:55     ` Allison Henderson
2026-04-07  1:19   ` Jakub Kicinski
2026-04-07  7:54     ` Allison Henderson
2026-04-05  4:16 ` [PATCH net v1 2/2] net/rds: Restrict use of RDS/IB to the initial network namespace Allison Henderson
2026-04-07  1:19   ` Jakub Kicinski

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=20260407011900.3596320-1-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=achender@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rds-devel@oss.oracle.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.