netdev - Re: [PATCH net-next v2] net/smc: add full IPv6 support for SMC

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: <20251028101822.GB38488@j66a10360.sqa.eu95>
Date: Tue, 28 Oct 2025 18:18:22 +0800
From: "D. Wythe" <alibuda@...ux.alibaba.com    >
To: Dust Li <dust.li@...ux.alibaba.com>
Cc: "D. Wythe" <alibuda@...ux.alibaba.com>, mjambigi@...ux.ibm.com,
	wenjia@...ux.ibm.com, wintera@...ux.ibm.com,
	tonylu@...ux.alibaba.com, guwen@...ux.alibaba.com, kuba@...nel.org,
	davem@...emloft.net, netdev@...r.kernel.org,
	linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org,
	pabeni@...hat.com, edumazet@...gle.com, sidraya@...ux.ibm.com,
	jaka@...ux.ibm.com
Subject: Re: [PATCH net-next v2] net/smc: add full IPv6 support for SMC

On Thu, Oct 23, 2025 at 09:34:22AM +0800, Dust Li wrote:
> On 2025-10-22 11:23:09, D. Wythe wrote:
> >The current SMC implementation is IPv4-centric. While it contains a
> >workaround for IPv4-mapped IPv6 addresses, it lacks a functional path
> >for native IPv6, preventing its use in modern dual-stack or IPv6-only
> >networks.
> >
> >This patch introduces full, native IPv6 support by refactoring the
> >address handling mechanism to be IP-version agnostic, which is
> >achieved by:
> >
> >- Introducing a generic `struct smc_ipaddr` to abstract IP addresses.
> >- Implementing an IPv6-specific route lookup function.
> >- Extend GID matching logic for both IPv4 and IPv6 addresses
> >
> >With these changes, SMC can now discover RDMA devices and establish
> >connections over both native IPv4 and IPv6 networks.
> 
> Tested it with link local ipv6 address, it still doesn't work as
> expected, while TCP works fine.
> 
> #smc_run ./sockperf tp --tcp -i fe80::c679:7b0:4a4b:d5cc%eth2
> sockperf: == version #3.10-23.gited92afb185e6.dirty ==
> sockperf: ERROR: Can`t connect socket (errno=104 Connection reset by peer)
> 
> Best regards,
> Dust
>

This is a long-standing bug. When both smcd and smcrv1 devices are
present in the system, if the smc_clc_prfx_set function fails, the
current logic only clears pclc_base->hdr.typev1 = SMC_TYPE_N, but
neglects to clear ini->smc_type_v1.

This leads to a serious issue: when subsequently constructing the smc
proposal message, the message content is organized according to the v1 +
smcd format based on the uncleared ini->smc_type_v1.

However, because pclc_base->hdr.typev1 has been cleared, When the server
receives such a proposal message, where the type in the header does not
match the content, it immediately fails.

Previously, I considered this issue to be logically unrelated to IPv6
support, so I didn't plan to send this bugfix along. However, in an
IPv6-only environment, this function is guaranteed to return an error
when only link-local address is present. This inevitably triggers the
problem in your test cases, which I hadn't anticipated. I will include
its fix in the next release.

Best wishes,
D. Wythe