Re: [PATCH ipsec 7/7] xfrm: leave the sequence counter unchanged on ESN overflow

["Jérémy Jean" <jeremy.jean@oss.cyber.gouv.fr>]

Hello Sabrina,

On 2026-10-01 13:24, Sabrina Dubroca wrote:
> 2026-09-30, 14:45:24 +0000, Jérémy Jean wrote:
>> When the 64-bit ESN counter overflows, 
>> xfrm_replay_overflow_offload_esn()
>> rejects the packet and rolls back the stored counter. It decrements
>> replay_esn->oseq even though only the local oseq has advanced, which
>> can later induce a reuse of the last sequence number and the
>> corresponding AES-GCM nonce. Both IPv4 and IPv6 are affected, yet,
>> processing about 2^64 packets under a single key is required to
>> trigger this bug, which is highly unlikely in regular use cases.
>> 
>> Leave the stored low word unchanged on overflow. The high word still
>> needs to be restored because it was already incremented.
> 
> nit: using "low word" and "high word" instead of the actual variable
> names doesn't help the readability of your commit messages

Right, I could specify that. How do you suggest I do that? Should I send
a v2 for this single 7/7 patch, resend a v2 for the full 7-patch series
(possibly in a couple of days in case there are some other public
comments), or another option? Thanks.

>> Fixes: d7dbefc45cf5 ("xfrm: Add xfrm_replay_overflow functions for 
>> offloading")
>> Cc: stable@vger.kernel.org
>> Assisted-by: LLM
>> Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
>> ---
>>  net/xfrm/xfrm_replay.c | 1 -
>>  1 file changed, 1 deletion(-)
> 
> I ran into that one as well while I was reviewing your previous
> patches, but didn't get around to posting a patch.

Good, thanks for letting me know.

> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>