Re: [PATCH ipsec 4/7] xfrm: prevent AES-GCM nonce reuse after early GSO

[Usman Malik <usmalik90@gmail.com>]

On Wed, 30 Sep 2026 14:45:21 +0000, Jeremy Jean wrote:
> In the software ESP offload path, xfrm_output_gso() leaves its segments
> sharing a secpath extension. Each segment gets its own ESP sequence
> number, but stores it in the same xo->seq field for IV generation.

Tested this patch as posted (patchwork 14858684) on v7.3 against the
same build without it. Both kernels carry patch 1/7 of this series
and no other patch of it, plus my "xfrm: use software GSO for inner
tunnels without crypto offload" v1, which does not change the
tunnel-mode path and moves the transport-mode case onto it. The test
ran in a VM with two network namespaces on a veth, TCP through an
ip6tnl tunnel over an rfc4106(gcm(aes)) SA, esp6_offload loaded, a
tbf qdisc on the egress veth that queues the segments, 3 MB per run
and 3 runs per case. The sender capture was decrypted with the SA
keys.

Without this patch every queued run reused IV values, 92, 51 and 51
per run over a tunnel-mode SA and 50, 51 and 50 over a transport-mode
SA, each shared by up to 7 segments of one GSO packet, with ct1 XOR
ct2 equal to pt1 XOR pt2 for one pair under each value. With this
patch, 0 in all 6 runs. A kernel with 1/7 alone gave 50, 50 and 51
over the tunnel-mode SA. Without the qdisc every run was 0 on every
kernel.

Tested-by: Usman Malik <usmanmalik@engineer.com>