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

[Sabrina Dubroca <sd@queasysnail.net>]

2026-10-01, 13:37:54 +0200, Jérémy Jean wrote:
> 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.

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).

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

-- 
Sabrina