netdev - Re: [PATCH net] net/smc: fix mismatch between CLC header and proposal extensions

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] [day] [month] [year] [list]

Message-ID: <95bd9c85-8241-4040-bbd0-bcac3ffc78f7@linux.ibm.com>
Date: Mon, 3 Nov 2025 09:28:22 +0100
From: Alexandra Winter <wintera@...ux.ibm.com>
To: "D. Wythe" <alibuda@...ux.alibaba.com>, mjambigi@...ux.ibm.com,
        wenjia@...ux.ibm.com, dust.li@...ux.alibaba.com,
        tonylu@...ux.alibaba.com, guwen@...ux.alibaba.com
Cc: 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] net/smc: fix mismatch between CLC header and proposal
 extensions



On 31.10.25 04:18, D. Wythe wrote:
> The current CLC proposal message construction uses a mix of
> `ini->smc_type_v1/v2` and `pclc_base->hdr.typev1/v2` to decide whether
> to include optional extensions (IPv6 prefix extension for v1, and v2
> extension). This leads to a critical inconsistency: when
> `smc_clc_prfx_set()` fails - for example, in IPv6-only environments with
> only link-local addresses, or when the local IP address and the outgoing
> interface’s network address are not in the same subnet.
> 
> As a result, the proposal message is assembled using the stale
> `ini->smc_type_v1` value—causing the IPv6 prefix extension to be
> included even though the header indicates v1 is not supported.
> The peer then receives a malformed CLC proposal where the header type
> does not match the payload, and immediately resets the connection.
> 
> Fix this by consistently using `pclc_base->hdr.typev1` and
> `pclc_base->hdr.typev2`—the authoritative fields that reflect the
> actual capabilities advertised in the CLC header—when deciding whether
> to include optional extensions, as required by the SMC-R v2
> specification ("V1 IP Subnet Extension and V2 Extension only present if
> applicable").


Just thinking out loud:
It seems to me that the 'ini' structure exists once per socket and is used
to pass information between many functions involved with the handshake.
Did you consider updating ini->smc_type_v1/v2 when `smc_clc_prfx_set()` fails,
and using ini as the authoritative source?
With your patch, it seems to me `ini->smc_type_v1` still contains a stale value,
which may lead to issues in other places or future code.