Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1492244
| From | Herbert Xu <herbert@gondor.apana.org.au> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 |
| Date | 2016-09-28 04:50 +0200 |
| Message-ID | <smd6y-Vb-5@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <skJ0R-2oQ-5@gated-at.bofh.it> <slFHz-5oB-23@gated-at.bofh.it> <slIcp-6Mu-15@gated-at.bofh.it> <slQWl-4bJ-5@gated-at.bofh.it> <slWyJ-7CX-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote:
>
> Also, does that mean that padlock_sha has similar problem?
> It does not seem to reserve any space for fallback __ctx and it calls
> init()/update()/export() with padlock_sha_desc's fallback:
>
> struct padlock_sha_desc {
> struct shash_desc fallback;
> };
>
> static struct shash_alg sha1_alg = {
> .descsize = sizeof(struct padlock_sha_desc),
Actually I was wrong when I said that the API couldn't handle
a dynamic fallback. It can and padlock-sha does the right thing
by updating descsize in the cra_init function.
So this is what vmx should do too.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Jan Stancek <jstancek@redhat.com> - 2016-09-24 02:30 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Marcelo Cerri <marcelo.cerri@canonical.com> - 2016-09-26 16:20 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Jan Stancek <jstancek@redhat.com> - 2016-09-26 20:00 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Herbert Xu <herbert@gondor.apana.org.au> - 2016-09-26 17:10 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Marcelo Cerri <marcelo.cerri@canonical.com> - 2016-09-26 19:50 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Herbert Xu <herbert@gondor.apana.org.au> - 2016-09-27 05:10 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Jan Stancek <jstancek@redhat.com> - 2016-09-27 11:10 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Marcelo Cerri <marcelo.cerri@canonical.com> - 2016-09-27 14:10 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Marcelo Cerri <marcelo.cerri@canonical.com> - 2016-09-27 21:50 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Herbert Xu <herbert@gondor.apana.org.au> - 2016-09-28 04:50 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Jan Stancek <jstancek@redhat.com> - 2016-09-28 09:50 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Marcelo Cerri <marcelo.cerri@canonical.com> - 2016-09-28 14:40 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Herbert Xu <herbert@gondor.apana.org.au> - 2016-09-28 14:50 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Marcelo Cerri <marcelo.cerri@canonical.com> - 2016-09-28 15:00 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Herbert Xu <herbert@gondor.apana.org.au> - 2016-09-28 15:20 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Herbert Xu <herbert@gondor.apana.org.au> - 2016-09-28 14:40 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Marcelo Cerri <marcelo.cerri@canonical.com> - 2016-09-28 14:30 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Herbert Xu <herbert@gondor.apana.org.au> - 2016-09-28 14:40 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> - 2016-09-28 15:30 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Jan Stancek <jstancek@redhat.com> - 2016-09-28 11:00 +0200
Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7 Herbert Xu <herbert@gondor.apana.org.au> - 2016-09-28 04:50 +0200
csiph-web