summaryrefslogtreecommitdiff
path: root/net/mac80211
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2016-10-26 15:02:01 +0100
committerJames Morris <james.l.morris@oracle.com>2016-10-27 16:03:27 +1100
commit7df3e59c3d1df4f87fe874c7956ef7a3d2f4d5fb (patch)
tree5a232a7bc6c456e08b59c0b5d58c8f109f553cc2 /net/mac80211
parent03dab869b7b239c4e013ec82aea22e181e441cfc (diff)
KEYS: Sort out big_key initialisation
big_key has two separate initialisation functions, one that registers the key type and one that registers the crypto. If the key type fails to register, there's no problem if the crypto registers successfully because there's no way to reach the crypto except through the key type. However, if the key type registers successfully but the crypto does not, big_key_rng and big_key_blkcipher may end up set to NULL - but the code neither checks for this nor unregisters the big key key type. Furthermore, since the key type is registered before the crypto, it is theoretically possible for the kernel to try adding a big_key before the crypto is set up, leading to the same effect. Fix this by merging big_key_crypto_init() and big_key_init() and calling the resulting function late. If they're going to be encrypted, we shouldn't be creating big_keys before we have the facilities to do the encryption available. The key type registration is also moved after the crypto initialisation. The fix also includes message printing on failure. If the big_key type isn't correctly set up, simply doing: dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s ought to cause an oops. Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted') Signed-off-by: David Howells <dhowells@redhat.com> cc: Peter Hlavaty <zer0mem@yahoo.com> cc: Kirill Marinushkin <k.marinushkin@gmail.com> cc: Artem Savkov <asavkov@redhat.com> cc: stable@vger.kernel.org Signed-off-by: James Morris <james.l.morris@oracle.com>
Diffstat (limited to 'net/mac80211')
0 files changed, 0 insertions, 0 deletions