On Thu, Apr 06, 2017 at 02:32:27PM +0200, Alexander Sverdlin wrote:
>
> > diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> > index 690deca..3556d8e 100644
> > --- a/crypto/af_alg.c
> > +++ b/crypto/af_alg.c
> > @@ -160,11 +160,11 @@ static int alg_bind(struct socket *sock, struct
> > sockaddr
The author meant to free the variable that was just allocated, instead
of the one that failed to be allocated, but made a simple typo. This
patch rectifies that.
Signed-off-by: Jason A. Donenfeld
Cc: sta...@vger.kernel.org
---
kernel/padata.c | 2 +-
1 file changed, 1
On Thu, Apr 06, 2017 at 04:16:10PM +0800, Herbert Xu wrote:
> This patch fixes the xfrm_user code to use the actual array size
> rather than the hard-coded CRYPTO_MAX_ALG_NAME length. This is
> because the array size is fixed at 64 bytes while we want to increase
> the in-kernel
On Thu, Apr 06, 2017 at 01:58:32PM -0700, David Miller wrote:
> From: Herbert Xu
> Date: Thu, 6 Apr 2017 16:15:09 +0800
>
> > As the final patch depends on all three it would be easiest if
> > we pushed the xfrm patch through the crypto tree. Steffen/David?
>
> No
From: Herbert Xu
Date: Thu, 6 Apr 2017 16:15:09 +0800
> As the final patch depends on all three it would be easiest if
> we pushed the xfrm patch through the crypto tree. Steffen/David?
No objections from me for this going through the crypto tree.
On 06/04/17 10:16, Herbert Xu wrote:
> This patch fixes the xfrm_user code to use the actual array size
> rather than the hard-coded CRYPTO_MAX_ALG_NAME length. This is
> because the array size is fixed at 64 bytes while we want to increase
> the in-kernel CRYPTO_MAX_ALG_NAME value.
>
>
On 06/04/17 10:16, Herbert Xu wrote:
> With the new explicit IV generators, we may now exceed the 64-byte
> length limit on the algorithm name, e.g., with
>
> echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic)))
>
> This patch extends the length limit to 128 bytes.
>
>
On 06/04/17 10:16, Herbert Xu wrote:
> This patch hard-codes CRYPTO_MAX_NAME in the user-space API to
> 64, which is the current value of CRYPTO_MAX_ALG_NAME. This patch
> also replaces all remaining occurences of CRYPTO_MAX_ALG_NAME
> in the user-space API with CRYPTO_MAX_NAME.
>
> This way the
Hi!
On 06/04/17 10:15, Herbert Xu wrote:
> On Thu, Mar 16, 2017 at 03:16:29PM +0100, Alexander Sverdlin wrote:
>> This is a regression caused by 856e3f4092
>> ("crypto: seqiv - Add support for new AEAD interface")
>>
>> As I've said above, I can offer one of the two solutions, which patch should
On Thu, Apr 06 2017 at 5:29am -0400,
Herbert Xu wrote:
> On Fri, Mar 10, 2017 at 02:44:26PM +0100, Ondrej Mosnacek wrote:
> > Hi all,
> >
> > I was tasked to post a summary the whole dm-crypt IV generation
> > problem and all the suggested solutions along with
Hi!
On 06/04/17 10:16, Herbert Xu wrote:
> This patch removes the hard-coded 64-byte limit on the length
> of the algorithm name through bind(2). The address length can
> now exceed that. The user-space structure remains unchanged.
> In order to use a longer name simply extend the salg_name
On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote:
>
> I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
> skcipher"). The s5p-sss driver stays the same... but the xts changes and
> as a result we have a NULL pointer dereference (actually of value
> 0004):
> [
On Fri, Mar 10, 2017 at 02:44:26PM +0100, Ondrej Mosnacek wrote:
> Hi all,
>
> I was tasked to post a summary the whole dm-crypt IV generation
> problem and all the suggested solutions along with their drawbacks, so
> here it goes...
Thanks for the summary. It looks good to me.
Something else
This patch hard-codes CRYPTO_MAX_NAME in the user-space API to
64, which is the current value of CRYPTO_MAX_ALG_NAME. This patch
also replaces all remaining occurences of CRYPTO_MAX_ALG_NAME
in the user-space API with CRYPTO_MAX_NAME.
This way the user-space API will not be modified when we
This patch fixes the xfrm_user code to use the actual array size
rather than the hard-coded CRYPTO_MAX_ALG_NAME length. This is
because the array size is fixed at 64 bytes while we want to increase
the in-kernel CRYPTO_MAX_ALG_NAME value.
Signed-off-by: Herbert Xu
This patch removes the hard-coded 64-byte limit on the length
of the algorithm name through bind(2). The address length can
now exceed that. The user-space structure remains unchanged.
In order to use a longer name simply extend the salg_name array
beyond its defined 64 bytes length.
With the new explicit IV generators, we may now exceed the 64-byte
length limit on the algorithm name, e.g., with
echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic)))
This patch extends the length limit to 128 bytes.
Reported-by: Alexander Sverdlin
On Thu, Mar 16, 2017 at 03:16:29PM +0100, Alexander Sverdlin wrote:
>
> This is a regression caused by 856e3f4092
> ("crypto: seqiv - Add support for new AEAD interface")
>
> As I've said above, I can offer one of the two solutions, which patch should
> I send?
> Or do you see any better
18 matches
Mail list logo