All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Peter Hlavaty <zer0mem@yahoo.com>,
	Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: dhowells@redhat.com, Greg KH <gregkh@linuxfoundation.org>,
	James Morris <james.l.morris@oracle.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [RFC][PATCH] KEYS: Sort out big_key initialisation
Date: Wed, 27 Jul 2016 14:23:35 +0100	[thread overview]
Message-ID: <10390.1469625815@warthog.procyon.org.uk> (raw)
In-Reply-To: <20160722214155.GA13726@kroah.com>

The attached patch *might* fix the problem that's being seen.  It certainly
fixes the init problem.

David
---
commit 57b7807d7f7ac69a818edb2ba4b1ec17b10cee4b
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jul 27 13:45:02 2016 +0100

    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.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Peter Hlavaty <zer0mem@yahoo.com>
    cc: Kirill Marinushkin <k.marinushkin@gmail.com>
    cc: stable@vger.kernel.org

diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index 9e443fccad4c..e9cc02e7aba8 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -9,6 +9,7 @@
  * 2 of the Licence, or (at your option) any later version.
  */
 
+#define pr_fmt(fmt) "big_key: "fmt
 #include <linux/init.h>
 #include <linux/seq_file.h>
 #include <linux/file.h>
@@ -336,43 +337,47 @@ error:
  */
 static int __init big_key_init(void)
 {
-	return register_key_type(&key_type_big_key);
-}
-
-/*
- * Initialize big_key crypto and RNG algorithms
- */
-static int __init big_key_crypto_init(void)
-{
-	int ret = -EINVAL;
+	struct crypto_blkcipher *cipher;
+	struct crypto_rng *rng;
+	int ret;
 
-	/* init RNG */
-	big_key_rng = crypto_alloc_rng(big_key_rng_name, 0, 0);
-	if (IS_ERR(big_key_rng)) {
-		big_key_rng = NULL;
-		return -EFAULT;
+	rng = crypto_alloc_rng(big_key_rng_name, 0, 0);
+	if (IS_ERR(rng)) {
+		pr_err("Can't alloc rng: %ld\n", PTR_ERR(rng));
+		return PTR_ERR(rng);
 	}
 
+	big_key_rng = rng;
+
 	/* seed RNG */
-	ret = crypto_rng_reset(big_key_rng, NULL, crypto_rng_seedsize(big_key_rng));
-	if (ret)
-		goto error;
+	ret = crypto_rng_reset(rng, NULL, crypto_rng_seedsize(rng));
+	if (ret) {
+		pr_err("Can't reset rng: %d\n", ret);
+		goto error_rng;
+	}
 
-	/* init block cipher */
-	big_key_blkcipher = crypto_alloc_blkcipher(big_key_alg_name, 0, 0);
-	if (IS_ERR(big_key_blkcipher)) {
-		big_key_blkcipher = NULL;
-		ret = -EFAULT;
-		goto error;
+	cipher = crypto_alloc_blkcipher(big_key_alg_name, 0, 0);
+	if (IS_ERR(cipher)) {
+		ret = PTR_ERR(cipher);
+		pr_err("Can't alloc crypto: %d\n", ret);
+		goto error_rng;
+	}
+
+	big_key_blkcipher = cipher;
+	
+	ret = register_key_type(&key_type_big_key);
+	if (ret < 0) {
+		pr_err("Can't register type: %d\n", ret);
+		goto error_cipher;
 	}
 
 	return 0;
 
-error:
+error_cipher:
+	crypto_free_blkcipher(big_key_blkcipher);
+error_rng:
 	crypto_free_rng(big_key_rng);
-	big_key_rng = NULL;
 	return ret;
 }
 
-device_initcall(big_key_init);
-late_initcall(big_key_crypto_init);
+late_initcall(big_key_init);

  parent reply	other threads:[~2016-07-27 13:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <47074.85917.bm@smtp228.mail.bf1.yahoo.com>
     [not found] ` <531421.11642.bm@smtp201.mail.bf1.yahoo.com>
2016-07-22 21:41   ` [zer0mem@yahoo.com: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master] Greg KH
2016-07-25 13:00     ` David Howells
2016-07-25 21:45       ` David Howells
2016-07-26  7:45         ` David Howells
2016-07-26  9:17           ` Vegard Nossum
2016-07-26 10:12           ` David Howells
2016-07-25 13:06     ` David Howells
2016-07-25 15:27     ` David Howells
2016-07-25 20:17       ` Greg KH
2016-07-26 22:45     ` David Howells
2016-08-25 22:08       ` Kirill Marinushkin
2016-07-27 13:23     ` David Howells [this message]
2016-08-10 18:20       ` [RFC][PATCH] KEYS: Sort out big_key initialisation Kirill Marinushkin
2016-08-11 19:48       ` Kirill Marinushkin
2016-08-27 10:22     ` [zer0mem@yahoo.com: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master] Kirill Marinushkin
2016-08-09 16:38 [RFC][PATCH] KEYS: Sort out big_key initialisation Kirill Marinushkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10390.1469625815@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.l.morris@oracle.com \
    --cc=k.marinushkin@gmail.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=zer0mem@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.