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

On 2026-10-01 13:45, Sabrina Dubroca wrote:

2026-10-01, 13:37:54 +0200, Jérémy Jean wrote:

quoted

Hello Sabrina,

On 2026-10-01 13:24, Sabrina Dubroca wrote:

quoted

2026-09-30, 14:45:24 +0000, Jérémy Jean wrote:

quoted

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.

Unless there are other reasons to send a v2 (ie some more important
issues in a patch/in the series), or if someone requests it, then no,
it's not necessary. That's just a preference in wording (and possibly
just mine, maybe it doesn't bother anyone else).

Okay, I'm not doing anything just yet then.

In general, do not resend a single patch, always the full series.

Noted, thanks for the advice.

Cheers,
Jérémy