From: "Power, Ciara" <ciara.power@intel.com>
To: Luca Boccassi <luca.boccassi@gmail.com>
Cc: "stable@dpdk.org" <stable@dpdk.org>,
"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
"Ji, Kai" <kai.ji@intel.com>
Subject: RE: [PATCH 22.11] crypto/ipsec_mb: fix incorrectly setting cipher keys
Date: Mon, 8 Apr 2024 07:17:04 +0000 [thread overview]
Message-ID: <SN7PR11MB7639BDC5CA4D3B8EAA719977E6002@SN7PR11MB7639.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAMw=ZnTaj6eEypEqoJ5WpVvx8W3sbzPvGBC6mhworw3xDy0g+Q@mail.gmail.com>
Hi Luca,
> -----Original Message-----
> From: Luca Boccassi <luca.boccassi@gmail.com>
> Sent: Friday, April 5, 2024 3:44 PM
> To: Power, Ciara <ciara.power@intel.com>
> Cc: stable@dpdk.org; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>;
> Ji, Kai <kai.ji@intel.com>
> Subject: Re: [PATCH 22.11] crypto/ipsec_mb: fix incorrectly setting cipher keys
>
> On Fri, 5 Apr 2024 at 11:46, Ciara Power <ciara.power@intel.com> wrote:
> >
> > The encryption and decryption keys were incorrectly being reset based
> > on authentication algorithm after already being set earlier in the
> > code based on cipher algorithm.
> > In cases when 3DES was used, the keys were being incorrectly
> > overwritten.
> >
> > For CPU path, there is no need to have the keys set for XCBC and CMAC
> > cases.
> >
> > Fixes: 010230a1543b ("crypto/aesni_mb: support Chacha20-Poly1305")
> > Fixes: b0a37e8cd2ac ("crypto/ipsec_mb: fix cipher key setting")
> > Fixes: a2c6d3f34f90 ("crypto/aesni_mb: support CPU crypto")
> >
> > Signed-off-by: Ciara Power <ciara.power@intel.com>
> > ---
> > Cc: pablo.de.lara.guarch@intel.com
> > ---
> > drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 14 --------------
> > 1 file changed, 14 deletions(-)
>
> I have already tagged rc1 - is this fixing a regression introduced in
> rc1 itself? If not, how important is it, could it wait for the next release?
No, it is fixing an issue that existed before 22.11 itself. I have also sent the fix for 21.11 LTS.
The bug was reported by an external user as it caused seg faults for their algorithm use case, so the sooner the better for fix to be merged.
Would it be suitable for merge in rc2?
Thanks,
Ciara
next prev parent reply other threads:[~2024-04-08 7:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-05 10:38 Ciara Power
2024-04-05 14:43 ` Luca Boccassi
2024-04-08 7:17 ` Power, Ciara [this message]
2024-04-08 9:22 ` Luca Boccassi
2024-04-10 7:56 ` Power, Ciara
2024-04-10 13:07 ` Luca Boccassi
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=SN7PR11MB7639BDC5CA4D3B8EAA719977E6002@SN7PR11MB7639.namprd11.prod.outlook.com \
--to=ciara.power@intel.com \
--cc=kai.ji@intel.com \
--cc=luca.boccassi@gmail.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=stable@dpdk.org \
/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;
as well as URLs for NNTP newsgroup(s).