From: Tariq Toukan <tariqt@nvidia.com>
To: "Jérémy Jean" <jeremy.jean@oss.cyber.gouv.fr>,
"Tariq Toukan" <tariqt@nvidia.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
Sabrina Dubroca <sd@queasysnail.net>,
Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>, Mark Bloch <mbloch@nvidia.com>,
Boris Pismenny <borisp@nvidia.com>,
netdev@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH ipsec 5/7] net/mlx5e: Use the packet sequence number for the IPsec IV
Date: Tue, 6 Oct 2026 09:49:49 +0300 [thread overview]
Message-ID: <76e305ba-47c0-4028-afdf-294dcfea11de@nvidia.com> (raw)
In-Reply-To: <e65b8b035eadcb1a776278b0887a57d7@oss.cyber.gouv.fr>
On 05/10/2026 21:28, Jérémy Jean wrote:
> On 2026-10-05 15:50, Jérémy Jean wrote:
>> Hello Tariq,
>>
>> On 2026-10-05 15:06, Tariq Toukan wrote:
>>> On 30/09/2026 17:45, Jérémy Jean wrote:
>>>> mlx5e_ipsec_set_iv_esn() may decrement xo->seq.hi for a GSO skb based
>>>> on the SA's current output counter. The metadata already contains the
>>>> high word for the first packet, so this can produce the wrong IV.
>>>>
>>>> For a three-segment GSO skb starting at (H, 0), oseq is 2 and
>>>> oseq - gso_segs wraps to 0xffffffff. The helper then uses (H-1, 0)
>>>> for the IV instead of (H, 0). This can create a situation where GCM
>>>> reuses a nonce.
>>>>
>>>> Remove the high-word adjustment and use xo->seq directly to generate
>>>> the IV.
>>>>
>>>> Fixes: cb01008390bb ("net/mlx5: IPSec, Add support for ESN")
>>>> Cc: stable@vger.kernel.org
>>>> Assisted-by: LLM
>>>> Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
>>>> ---
>>>> .../mellanox/mlx5/core/en_accel/ipsec_rxtx.c | 12
>>>> +-----------
>>>> 1 file changed, 1 insertion(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/
>>>> ipsec_rxtx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/
>>>> ipsec_rxtx.c
>>>> index 6056106edcc6..4aa9f9c52f57 100644
>>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
>>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
>>>> @@ -153,21 +153,11 @@ static void mlx5e_ipsec_set_swp(struct sk_buff
>>>> *skb,
>>>> void mlx5e_ipsec_set_iv_esn(struct sk_buff *skb, struct xfrm_state
>>>> *x,
>>>> struct xfrm_offload *xo)
>>>> {
>>>> - struct xfrm_replay_state_esn *replay_esn = x->replay_esn;
>>>> - __u32 oseq = replay_esn->oseq;
>>>> int iv_offset;
>>>> __be64 seqno;
>>>> - u32 seq_hi;
>>>> -
>>>> - if (unlikely(skb_is_gso(skb) && oseq <
>>>> MLX5E_IPSEC_ESN_SCOPE_MID &&
>>>> - MLX5E_IPSEC_ESN_SCOPE_MID < (oseq - skb_shinfo(skb)-
>>>> >gso_segs))) {
>>>> - seq_hi = xo->seq.hi - 1;
>>>> - } else {
>>>> - seq_hi = xo->seq.hi;
>>>> - }
>>>> /* Place the SN in the IV field */
>>>> - seqno = cpu_to_be64(xo->seq.low + ((u64)seq_hi << 32));
>>>> + seqno = cpu_to_be64(xo->seq.low + ((u64)xo->seq.hi << 32));
>>>> iv_offset = skb_transport_offset(skb) + sizeof(struct
>>>> ip_esp_hdr);
>>>> skb_store_bits(skb, iv_offset, &seqno, 8);
>>>> }
>>>
>>> Thanks for your patch.
>>>
>>> Doesn't this make mlx5e_ipsec_set_iv_esn() identical to
>>> mlx5e_ipsec_set_iv()?
>>>
>>> I wouldn't keep both copies then..
>>
>> Good point: after a quick check, indeed you are probably right.
>> I will look to simplify this in a new version of the patch series.
>>
>> Jérémy
>
> It seems to me that a delete only patch would be okay then? (see
> patch below).
> The removal of the check in mlx5e_ipsec_set_esn_ops() makes
> mlx5e_ipsec_set_iv() the only callable function. Then it seems
> one can simply remove lines. Do you confirm?
>
>
From a quick look, it seems we can do even more by totally removing the
set_iv_op function pointer.
> .../mellanox/mlx5/core/en_accel/ipsec.c | 5 -----
> .../mellanox/mlx5/core/en_accel/ipsec_rxtx.c | 22 -------------------
> .../mellanox/mlx5/core/en_accel/ipsec_rxtx.h | 2 --
> 3 files changed, 29 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> index db260e3..43ef5b3 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> @@ -659,11 +659,6 @@ static void mlx5e_ipsec_set_esn_ops(struct
> mlx5e_ipsec_sa_entry *sa_entry)
> x->xso.dir != XFRM_DEV_OFFLOAD_OUT)
> return;
>
> - if (x->props.flags & XFRM_STATE_ESN) {
> - sa_entry->set_iv_op = mlx5e_ipsec_set_iv_esn;
> - return;
> - }
> -
> sa_entry->set_iv_op = mlx5e_ipsec_set_iv;
> }
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/
> ipsec_rxtx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/
> ipsec_rxtx.c
> index 6056106..9ffe094 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
> @@ -150,28 +150,6 @@ static void mlx5e_ipsec_set_swp(struct sk_buff *skb,
>
> }
>
> -void mlx5e_ipsec_set_iv_esn(struct sk_buff *skb, struct xfrm_state *x,
> - struct xfrm_offload *xo)
> -{
> - struct xfrm_replay_state_esn *replay_esn = x->replay_esn;
> - __u32 oseq = replay_esn->oseq;
> - int iv_offset;
> - __be64 seqno;
> - u32 seq_hi;
> -
> - if (unlikely(skb_is_gso(skb) && oseq < MLX5E_IPSEC_ESN_SCOPE_MID &&
> - MLX5E_IPSEC_ESN_SCOPE_MID < (oseq -
> skb_shinfo(skb)->gso_segs))) {
> - seq_hi = xo->seq.hi - 1;
> - } else {
> - seq_hi = xo->seq.hi;
> - }
> -
> - /* Place the SN in the IV field */
> - seqno = cpu_to_be64(xo->seq.low + ((u64)seq_hi << 32));
> - iv_offset = skb_transport_offset(skb) + sizeof(struct ip_esp_hdr);
> - skb_store_bits(skb, iv_offset, &seqno, 8);
> -}
> -
> void mlx5e_ipsec_set_iv(struct sk_buff *skb, struct xfrm_state *x,
> struct xfrm_offload *xo)
> {
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/
> ipsec_rxtx.h b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/
> ipsec_rxtx.h
> index 45b0d19..a3d92c9 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.h
> @@ -53,8 +53,6 @@ struct mlx5e_accel_tx_ipsec_state {
>
> #ifdef CONFIG_MLX5_EN_IPSEC
>
> -void mlx5e_ipsec_set_iv_esn(struct sk_buff *skb, struct xfrm_state *x,
> - struct xfrm_offload *xo);
> void mlx5e_ipsec_set_iv(struct sk_buff *skb, struct xfrm_state *x,
> struct xfrm_offload *xo);
> bool mlx5e_ipsec_handle_tx_skb(struct net_device *netdev,
next prev parent reply other threads:[~2026-10-06 6:49 UTC|newest]
Thread overview: 23+ 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 ` [PATCH ipsec 2/7] xfrm: esp4: " Jérémy Jean
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-10-14 14:10 ` Sabrina Dubroca
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 [this message]
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=76e305ba-47c0-4028-afdf-294dcfea11de@nvidia.com \
--to=tariqt@nvidia.com \
--cc=borisp@nvidia.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=jeremy.jean@oss.cyber.gouv.fr \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.