user/sven/linux.git/security, branch v4.12.5

KEYS: DH: validate __spare field

2017-07-21T04:59:12Z

commit 4f9dabfaf8df971f8a3b6aa324f8f817be38d538 upstream. 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. Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

selinux: fix double free in selinux_parse_opts_str()

2017-06-13T07:34:22Z

This patch is based on a discussion generated by an earlier patch from Tetsuo Handa: * https://marc.info/?t=149035659300001&r=1&w=2 The double free problem involves the mnt_opts field of the security_mnt_opts struct, selinux_parse_opts_str() frees the memory on error, but doesn't set the field to NULL so if the caller later attempts to call security_free_mnt_opts() we trigger the problem. In order to play it safe we change selinux_parse_opts_str() to call security_free_mnt_opts() on error instead of free'ing the memory directly. This should ensure that everything is handled correctly, regardless of what the caller may do. Fixes: e0007529893c1c06 ("LSM/SELinux: Interfaces to allow FS to control mount options") Cc: stable@vger.kernel.org Cc: Tetsuo Handa Reported-by: Dmitry Vyukov Signed-off-by: Paul Moore Signed-off-by: James Morris

KEYS: fix refcount_inc() on zero

2017-06-09T03:29:50Z

If a key's refcount is dropped to zero between key_lookup() peeking at the refcount and subsequently attempting to increment it, refcount_inc() will see a zero refcount. Here, refcount_inc() will WARN_ONCE(), and will *not* increment the refcount, which will remain zero. Once key_lookup() drops key_serial_lock, it is possible for the key to be freed behind our back. This patch uses refcount_inc_not_zero() to perform the peek and increment atomically. Fixes: fff292914d3a2f1e ("security, keys: convert key.usage from atomic_t to refcount_t") Signed-off-by: Mark Rutland Signed-off-by: David Howells Cc: David Windsor Cc: Elena Reshetova Cc: Hans Liljestrand Cc: James Morris Cc: Kees Cook Cc: Peter Zijlstra Signed-off-by: James Morris

KEYS: Convert KEYCTL_DH_COMPUTE to use the crypto KPP API

2017-06-09T03:29:50Z

The initial Diffie-Hellman computation made direct use of the MPI library because the crypto module did not support DH at the time. Now that KPP is implemented, KEYCTL_DH_COMPUTE should use it to get rid of duplicate code and leverage possible hardware acceleration. This fixes an issue whereby the input to the KDF computation would include additional uninitialized memory when the result of the Diffie-Hellman computation was shorter than the input prime number. Signed-off-by: Mat Martineau Signed-off-by: David Howells Signed-off-by: James Morris

KEYS: DH: ensure the KDF counter is properly aligned

2017-06-09T03:29:49Z

Accessing a 'u8[4]' through a '__be32 *' violates alignment rules. Just make the counter a __be32 instead. Signed-off-by: Eric Biggers Signed-off-by: David Howells Acked-by: Stephan Mueller Signed-off-by: James Morris

KEYS: DH: don't feed uninitialized "otherinfo" into KDF

2017-06-09T03:29:49Z

If userspace called KEYCTL_DH_COMPUTE with kdf_params containing NULL otherinfo but nonzero otherinfolen, the kernel would allocate a buffer for the otherinfo, then feed it into the KDF without initializing it. Fix this by always doing the copy from userspace (which will fail with EFAULT in this scenario). Signed-off-by: Eric Biggers Signed-off-by: David Howells Acked-by: Stephan Mueller Signed-off-by: James Morris

KEYS: DH: forbid using digest_null as the KDF hash

2017-06-09T03:29:49Z

Requesting "digest_null" in the keyctl_kdf_params caused an infinite loop in kdf_ctr() because the "null" hash has a digest size of 0. Fix it by rejecting hash algorithms with a digest size of 0. Signed-off-by: Eric Biggers Signed-off-by: David Howells Acked-by: Stephan Mueller Signed-off-by: James Morris

KEYS: sanitize key structs before freeing

2017-06-09T03:29:48Z

While a 'struct key' itself normally does not contain sensitive information, Documentation/security/keys.txt actually encourages this: "Having a payload is not required; and the payload can, in fact, just be a value stored in the struct key itself." In case someone has taken this advice, or will take this advice in the future, zero the key structure before freeing it. We might as well, and as a bonus this could make it a bit more difficult for an adversary to determine which keys have recently been in use. This is safe because the key_jar cache does not use a constructor. Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris

KEYS: trusted: sanitize all key material

2017-06-09T03:29:48Z

As the previous patch did for encrypted-keys, zero sensitive any potentially sensitive data related to the "trusted" key type before it is freed. Notably, we were not zeroing the tpm_buf structures in which the actual key is stored for TPM seal and unseal, nor were we zeroing the trusted_key_payload in certain error paths. Cc: Mimi Zohar Cc: David Safford Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris

KEYS: encrypted: sanitize all key material

2017-06-09T03:29:48Z

For keys of type "encrypted", consistently zero sensitive key material before freeing it. This was already being done for the decrypted payloads of encrypted keys, but not for the master key and the keys derived from the master key. Out of an abundance of caution and because it is trivial to do so, also zero buffers containing the key payload in encrypted form, although depending on how the encrypted-keys feature is used such information does not necessarily need to be kept secret. Cc: Mimi Zohar Cc: David Safford Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris