netdev - Re: [PATCH v11 net-next 10/15] tcp: accecn: unset ECT if receive or send ACE=0 in AccECN negotiaion

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: <13f7664e-af7e-4c78-ba0c-b58b3ab59075@redhat.com>
Date: Wed, 28 Jan 2026 08:44:10 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, chia-yu.chang@...ia-bell-labs.com
Cc: edumazet@...gle.com, parav@...dia.com, linux-doc@...r.kernel.org,
 corbet@....net, horms@...nel.org, dsahern@...nel.org, kuniyu@...gle.com,
 bpf@...r.kernel.org, netdev@...r.kernel.org, dave.taht@...il.com,
 jhs@...atatu.com, stephen@...workplumber.org, xiyou.wangcong@...il.com,
 jiri@...nulli.us, davem@...emloft.net, andrew+netdev@...n.ch,
 donald.hunter@...il.com, ast@...erby.net, liuhangbin@...il.com,
 shuah@...nel.org, linux-kselftest@...r.kernel.org, ij@...nel.org,
 ncardwell@...gle.com, koen.de_schepper@...ia-bell-labs.com,
 g.white@...lelabs.com, ingemar.s.johansson@...csson.com,
 mirja.kuehlewind@...csson.com, cheshire@...le.com, rs.ietf@....at,
 Jason_Livingood@...cast.com, vidhi_goel@...le.com
Subject: Re: [PATCH v11 net-next 10/15] tcp: accecn: unset ECT if receive or
 send ACE=0 in AccECN negotiaion

On 1/27/26 9:09 PM, Jakub Kicinski wrote:
> On Fri, 23 Jan 2026 11:07:16 +0100 chia-yu.chang@...ia-bell-labs.com
> wrote:
>> Based on specification:
>>   https://tools.ietf.org/id/draft-ietf-tcpm-accurate-ecn-28.txt
>>
>> Based on Section 3.1.5 of AccECN spec (RFC9768), a TCP Server in
>> AccECN mode MUST NOT set ECT on any packet for the rest of the connection,
>> if it has received or sent at least one valid SYN or Acceptable SYN/ACK
>> with (AE,CWR,ECE) = (0,0,0) during the handshake.
>>
>> In addition, a host in AccECN mode that is feeding back the IP-ECN
>> field on a SYN or SYN/ACK MUST feed back the IP-ECN field on the
>> latest valid SYN or acceptable SYN/ACK to arrive.
> 
> FWIW this series is marked as Changes Requested in patchwork. 
> I don't think I did that, IDK why it's in that state :S

I was me. I went over the AI feedback and it looked legit and relevant
to me: AFAICS the listener socket status is wrongly updated instead of
the request socket and likely corrupted.

I was sure I sent the feedback email before updating the series status,
but I see it did not land anywhere - PEBKAC here, I'm sorry.

/P