>
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
Acked-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
> ---
>
> net/xfrm/xfrm_user.c |6 +++---
> 1 file changed, 3 insertio
limit to 128 bytes.
>
> Reported-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
Acked-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
> ---
&g
gt;
> This way the user-space API will not be modified when we raise
> the value of CRYPTO_MAX_ALG_NAME.
>
> Furthermore, the code has been updated to handle names longer than
> the user-space API. They will be truncated.
>
> Signed-off-by: Herbert Xu <herb...@gondor.apan
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
n - sizeof(*sa) - 1] = 0;
>
> type = alg_get_type(sa->salg_type);
> if (IS_ERR(type) && PTR_ERR(type) == -ENOENT) {
Why should userspace ever extend the structure if salg_name is hardcoded to 64
in if_alg.h?
This patch doesn't change the behavior at all, or am I missing something?
--
Best regards,
Alexander Sverdlin.
Hello!
On 10/03/17 12:55, Alexander Sverdlin wrote:
> Hello crypto maintainers!
>
> We've found and example of the ipsec algorithm combination, which doesn't fit
> into CRYPTO_MAX_ALG_NAME long buffers:
>
> ip x s add src 1.1.1.1 dst 1.1.1.2 proto esp spi 0 mode tunnel enc de
t are your thoughts?
--
Best regards,
Alexander Sverdlin.
