netdev - Re: [PATCH net-next] tcp: be less liberal in tsecr received while in SYN

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: <af310ccd-3b5f-4046-b8d7-ab38b76d4bde@kernel.org>
Date: Tue, 25 Feb 2025 11:09:50 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>, Simon Horman <horms@...nel.org>,
 Florian Westphal <fw@...len.de>, netdev@...r.kernel.org,
 eric.dumazet@...il.com, Jakub Kicinski <kuba@...nel.org>,
 Yong-Hao Zou <yonghaoz1994@...il.com>, "David S . Miller"
 <davem@...emloft.net>, Neal Cardwell <ncardwell@...gle.com>
Subject: Re: [PATCH net-next] tcp: be less liberal in tsecr received while in
 SYN_RECV state

Hi Paolo, Eric,

On 25/02/2025 10:59, Paolo Abeni wrote:
> On 2/24/25 12:06 PM, Eric Dumazet wrote:
>> Yong-Hao Zou mentioned that linux was not strict as other OS in 3WHS,
>> for flows using TCP TS option (RFC 7323)
>>
>> As hinted by an old comment in tcp_check_req(),
>> we can check the TSecr value in the incoming packet corresponds
>> to one of the SYNACK TSval values we have sent.
>>
>> In this patch, I record the oldest and most recent values
>> that SYNACK packets have used.
>>
>> Send a challenge ACK if we receive a TSecr outside
>> of this range, and increase a new SNMP counter.
>>
>> nstat -az | grep TcpExtTSECR_Rejected
>> TcpExtTSECR_Rejected            0                  0.0

(...)

> It looks like this change causes mptcp self-test failures:
> 
> https://netdev-3.bots.linux.dev/vmksft-mptcp/results/6642/1-mptcp-join-sh/stdout
> 
> ipv6 subflows creation fails due to the added check:
> 
> # TcpExtTSECR_Rejected            3                  0.0

You have been faster to report the issue :-)

> (for unknown reasons the ipv4 variant of the test is successful)

Please note that it is not the first time the MPTCP test suite caught
issues with the IPv6 stack. It is likely possible the IPv6 stack is less
covered than the v4 one in the net selftests. (Even if I guess here the
issue is only on MPTCP side.)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.