Re: [PATCH ipsec v2 3/7] xfrm: esp: use the current sequence number for AAD and offload

[sashiko-bot@kernel.org]

> When a GSO packet is split in software, esp_xmit() and esp6_xmit()
> advance xo->seq before software encryption or the handoff to the NIC.
> If the 64-bit sequence number of the segment is (H, 0xffffffff), the
> counter becomes (H+1, 0). Both the software ESN helpers and drivers
> such as Chelsio then use H+1 instead of H as part of the associated
> data that is authenticated.
> 
> However, the ESN 32 high bits are not present in the ESP header: the
> receiver reconstructs the 64-bit value from the received 32 low bits
> and its own replay state, and uses it to check cryptographic
> integrity. It uses H for this packet at the boundary, so the GCM tag
> computed by the sender with H+1 fails verification, as it is different
> from the one obtained by the receiver using H.
> 
> Use the high bits saved in esp->seqno for the software AAD. For
> hardware encryption, restore the current sequence after skb_ext_add()
> makes the secpath private, leaving the shared counter advanced for
> the remaining segments. Restore both halves because drivers can also
> use xo->seq to generate the IV.
> 
> Fixes: 3dca3f38cfb8 ("xfrm: Separate ESP handling from segmentation for GRO packets.")
> Fixes: 4b549ccce941 ("xfrm: replay: Fix ESN wrap around for GSO")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261108142652.1330952-1-Jeremy.Jean@oss.cyber.gouv.fr?part=3