On Sat, Jul 30, 2016 at 06:21:41PM +0200, Kirill Marinushkin wrote: > 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. > > Signed-off-by: David Howells <dhowells@xxxxxxxxxx> > Signed-off-by: Kirill Marinushkin <k.marinushkin@xxxxxxxxx> > --- > security/keys/Kconfig | 2 +- > security/keys/big_key.c | 62 +++++++++++++++++++++++++++---------------------- > 2 files changed, 35 insertions(+), 29 deletions(-) <formletter> This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. </formletter> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html