From: "Jérémy Jean" <Jeremy.Jean@oss.cyber.gouv.fr>
To: Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S . Miller" <davem@davemloft.net>,
"Sabrina Dubroca" <sd@queasysnail.net>,
"Saeed Mahameed" <saeedm@nvidia.com>,
"Leon Romanovsky" <leon@kernel.org>,
"Tariq Toukan" <tariqt@nvidia.com>,
"Mark Bloch" <mbloch@nvidia.com>,
"Boris Pismenny" <borisp@nvidia.com>,
netdev@vger.kernel.org,
"Jérémy Jean" <Jeremy.Jean@oss.cyber.gouv.fr>,
stable@vger.kernel.org
Subject: [PATCH ipsec 2/7] xfrm: esp4: use the current sequence number for the IV
Date: Wed, 30 Sep 2026 14:45:19 +0000 [thread overview]
Message-ID: <20260930144523.435271-4-Jeremy.Jean@oss.cyber.gouv.fr> (raw)
In-Reply-To: <20260930144523.435271-2-Jeremy.Jean@oss.cyber.gouv.fr>
When a GSO packet is split in software for IPv4 ESP,
validate_xmit_xfrm() calls esp_xmit() for each segment. These
segments have XFRM_GSO_SEGMENT set, but after the split, skb_is_gso()
returns false for each skb, so each call increments xo->seq.low by one
after writing the ESP sequence number.
The low bits are saved in seq before the increment, but esp.seqno is
set afterwards, using the saved low bits and the high bits from
xo->seq.hi.
When encryption is done in software with ESN enabled, the segment at
(H, 0xffffffff) uses (H+1, 0xffffffff) to generate the AES-GCM IV
because xo->seq.hi has already been incremented when the low bits
wrapped. One full 32-bit cycle later, if the packet at
(H+1, 0xffffffff) on the same SA is non-GSO, it generates the same IV.
Move the assignment to esp.seqno before xo->seq is advanced. This
saves H before the wrap increments xo->seq.hi to H+1, so the segment
at (H, 0xffffffff) generates its IV from (H, 0xffffffff).
Fixes: 4b549ccce941 ("xfrm: replay: Fix ESN wrap around for GSO")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
---
net/ipv4/esp4_offload.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv4/esp4_offload.c b/net/ipv4/esp4_offload.c
index abd77162f5e7..3a0aafe991f4 100644
--- a/net/ipv4/esp4_offload.c
+++ b/net/ipv4/esp4_offload.c
@@ -316,6 +316,7 @@ static int esp_xmit(struct xfrm_state *x, struct sk_buff *skb, netdev_features_
}
seq = xo->seq.low;
+ esp.seqno = cpu_to_be64(seq + ((u64)xo->seq.hi << 32));
esph = esp.esph;
esph->spi = x->id.spi;
@@ -334,8 +335,6 @@ static int esp_xmit(struct xfrm_state *x, struct sk_buff *skb, netdev_features_
if (xo->seq.low < seq)
xo->seq.hi++;
- esp.seqno = cpu_to_be64(seq + ((u64)xo->seq.hi << 32));
-
if (hw_offload && encap_type == UDP_ENCAP_ESPINUDP) {
/* In the XFRM stack, the encapsulation protocol is set to iphdr->protocol by
* setting *skb_mac_header(skb) (see esp_output_udp_encap()) where skb->mac_header
--
2.47.3
next prev parent reply other threads:[~2026-09-30 14:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 14:45 [PATCH ipsec 0/7] xfrm: fix ESP IV generation and ESN authentication Jérémy Jean
2026-09-30 14:45 ` [PATCH ipsec 1/7] xfrm: esp6: use the current sequence number for the IV Jérémy Jean
2026-09-30 14:45 ` Jérémy Jean [this message]
2026-09-30 14:45 ` [PATCH ipsec 3/7] xfrm: esp: use the current sequence number for AAD and offload Jérémy Jean
2026-09-30 14:45 ` [PATCH ipsec 4/7] xfrm: prevent AES-GCM nonce reuse after early GSO Jérémy Jean
2026-10-01 13:31 ` Sabrina Dubroca
2026-10-01 21:07 ` Jérémy Jean
2026-09-30 14:45 ` [PATCH ipsec 5/7] net/mlx5e: Use the packet sequence number for the IPsec IV Jérémy Jean
2026-10-01 11:42 ` Sabrina Dubroca
2026-10-01 19:33 ` Jérémy Jean
2026-10-05 13:06 ` Tariq Toukan
2026-10-05 13:50 ` Jérémy Jean
2026-10-05 18:28 ` Jérémy Jean
2026-10-06 6:49 ` Tariq Toukan
2026-10-06 8:51 ` Jérémy Jean
2026-09-30 14:45 ` [PATCH ipsec 6/7] xfrm: segment untrusted GSO packets before sequence allocation Jérémy Jean
2026-09-30 14:45 ` [PATCH ipsec 7/7] xfrm: leave the sequence counter unchanged on ESN overflow Jérémy Jean
2026-10-01 11:24 ` Sabrina Dubroca
2026-10-01 11:37 ` Jérémy Jean
2026-10-01 11:45 ` Sabrina Dubroca
2026-10-01 11:48 ` Jérémy Jean
2026-09-30 14:48 ` [PATCH ipsec 0/7] xfrm: fix ESP IV generation and ESN authentication netdev-bot+sinfo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260930144523.435271-4-Jeremy.Jean@oss.cyber.gouv.fr \
--to=jeremy.jean@oss.cyber.gouv.fr \
--cc=borisp@nvidia.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=leon@kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
--cc=sd@queasysnail.net \
--cc=stable@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox