linux.git/security/keys/dh.c, branch v5.2

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

2019-05-30T18:26:32+00:00

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman

crypto: shash - remove shash_desc::flags

2019-04-25T07:38:12+00:00

The flags field in 'struct shash_desc' never actually does anything.
The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP.
However, no shash algorithm ever sleeps, making this flag a no-op.

With this being the case, inevitably some users who can't sleep wrongly
pass MAY_SLEEP.  These would all need to be fixed if any shash algorithm
actually started sleeping.  For example, the shash_ahash_*() functions,
which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP
from the ahash API to the shash API.  However, the shash functions are
called under kmap_atomic(), so actually they're assumed to never sleep.

Even if it turns out that some users do need preemption points while
hashing large buffers, we could easily provide a helper function
crypto_shash_update_large() which divides the data into smaller chunks
and calls crypto_shash_update() and cond_resched() for each chunk.  It's
not necessary to have a flag in 'struct shash_desc', nor is it necessary
to make individual shash algorithms aware of this at all.

Therefore, remove shash_desc::flags, and document that the
crypto_shash_*() functions can be called from any context.

Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu

Revert "uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name"

2018-09-25T11:28:58+00:00

This changes UAPI, breaking iwd and libell:

  ell/key.c: In function 'kernel_dh_compute':
  ell/key.c:205:38: error: 'struct keyctl_dh_params' has no member named 'private'; did you mean 'dh_private'?
    struct keyctl_dh_params params = { .private = private,
                                        ^~~~~~~
                                        dh_private

This reverts commit 8a2336e549d385bb0b46880435b411df8d8200e8.

Fixes: 8a2336e549d3 ("uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name")
Signed-off-by: Lubomir Rintel 
Signed-off-by: David Howells 
cc: Randy Dunlap 
cc: Mat Martineau 
cc: Stephan Mueller 
cc: James Morris 
cc: "Serge E. Hallyn" 
cc: Mat Martineau 
cc: Andrew Morton 
cc: Linus Torvalds 
cc: 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name

2018-09-04T23:45:02+00:00

Since this header is in "include/uapi/linux/", apparently people want to
use it in userspace programs -- even in C++ ones.  However, the header
uses a C++ reserved keyword ("private"), so change that to "dh_private"
instead to allow the header file to be used in C++ userspace.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=191051
Link: http://lkml.kernel.org/r/0db6c314-1ef4-9bfa-1baa-7214dd2ee061@infradead.org
Fixes: ddbb41148724 ("KEYS: Add KEYCTL_DH_COMPUTE command")
Signed-off-by: Randy Dunlap 
Reviewed-by: Andrew Morton 
Cc: David Howells 
Cc: James Morris 
Cc: "Serge E. Hallyn" 
Cc: Mat Martineau 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux

2018-08-03T09:55:12+00:00

Merge mainline to pick up c7513c2a2714 ("crypto/arm64: aes-ce-gcm -
add missing kernel_neon_begin/end pair").

crypto: remove redundant type flags from tfm allocation

2018-07-08T16:30:29+00:00

Some crypto API users allocating a tfm with crypto_alloc_$FOO() are also
specifying the type flags for $FOO, e.g. crypto_alloc_shash() with
CRYPTO_ALG_TYPE_SHASH.  But, that's redundant since the crypto API will
override any specified type flag/mask with the correct ones.

So, remove the unneeded flags.

This patch shouldn't change any actual behavior.

Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu

dh key: fix rounding up KDF output length

2018-06-26T16:43:05+00:00

Commit 383203eff718 ("dh key: get rid of stack allocated array") changed
kdf_ctr() to assume that the length of key material to derive is a
multiple of the digest size.  The length was supposed to be rounded up
accordingly.  However, the round_up() macro was used which only gives
the correct result on power-of-2 arguments, whereas not all hash
algorithms have power-of-2 digest sizes.  In some cases this resulted in
a write past the end of the 'outbuf' buffer.

Fix it by switching to roundup(), which works for non-power-of-2 inputs.

Reported-by: syzbot+486f97f892efeb2075a3@syzkaller.appspotmail.com
Reported-by: syzbot+29d17b7898b41ee120a5@syzkaller.appspotmail.com
Reported-by: syzbot+8a608baf8751184ec727@syzkaller.appspotmail.com
Reported-by: syzbot+d04e58bd384f1fe0b112@syzkaller.appspotmail.com
Fixes: 383203eff718 ("dh key: get rid of stack allocated array")
Signed-off-by: Eric Biggers 
Acked-by: Kees Cook 
Acked-by: Tycho Andersen 
Signed-off-by: James Morris

dh key: get rid of stack allocated array for zeroes

2018-05-11T20:07:49+00:00

We're interested in getting rid of all of the stack allocated arrays in
the kernel: https://lkml.org/lkml/2018/3/7/621

This case is interesting, since we really just need an array of bytes that
are zero. The loop already ensures that if the array isn't exactly the
right size that enough zero bytes will be copied in. So, instead of
choosing this value to be the size of the hash, let's just choose it to be
32, since that is a common size, is not too big, and will not result in too
many extra iterations of the loop.

v2: split out from other patch, just hardcode array size instead of
    dynamically allocating something the right size
v3: fix typo of 256 -> 32

Signed-off-by: Tycho Andersen 
Reviewed-by: Kees Cook 
CC: David Howells 
CC: James Morris 
CC: "Serge E. Hallyn" 
CC: Eric Biggers 
Signed-off-by: James Morris

dh key: get rid of stack allocated array

2018-05-11T20:07:47+00:00

We're interested in getting rid of all of the stack allocated arrays in the
kernel: https://lkml.org/lkml/2018/3/7/621

This particular vla is used as a temporary output buffer in case there is
too much hash output for the destination buffer. Instead, let's just
allocate a buffer that's big enough initially, but only copy back to
userspace the amount that was originally asked for.

v2: allocate enough in the original output buffer vs creating a temporary
    output buffer

Signed-off-by: Tycho Andersen 
Reviewed-by: Kees Cook 
CC: David Howells 
CC: James Morris 
CC: "Serge E. Hallyn" 
CC: Eric Biggers 
Signed-off-by: James Morris

KEYS: DH: validate __spare field

2017-07-14T01:01:38+00:00

Syscalls must validate that their reserved arguments are zero and return
EINVAL otherwise.  Otherwise, it will be impossible to actually use them
for anything in the future because existing programs may be passing
garbage in.  This is standard practice when adding new APIs.

Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers 
Signed-off-by: David Howells 
Signed-off-by: James Morris