* [PATCH 0/3] KEYS: Fixes
@ 2016-10-26 14:01 David Howells
2016-10-26 14:01 ` [PATCH 1/3] KEYS: Fix short sprintf buffer in /proc/keys show function David Howells
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: David Howells @ 2016-10-26 14:01 UTC (permalink / raw)
To: jmorris; +Cc: dhowells, linux-security-module, keyrings, linux-kernel
Hi James,
Can you pull these patches please and pass them on to Linus? They include
the following:
(1) Fix a buffer overflow when displaying /proc/keys [CVE-2016-7042].
(2) Fix broken initialisation in the big_key implementation that can
result in an oops.
(3) Make big_key depend on having a random number generator available in
Kconfig.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
Tagged thusly:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
keys-fixes-20161026
David
---
Artem Savkov (1):
security/keys: make BIG_KEYS dependent on stdrng.
David Howells (2):
KEYS: Fix short sprintf buffer in /proc/keys show function
KEYS: Sort out big_key initialisation
security/keys/Kconfig | 2 +-
security/keys/big_key.c | 59 +++++++++++++++++++++++++----------------------
security/keys/proc.c | 2 +-
3 files changed, 34 insertions(+), 29 deletions(-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/3] KEYS: Fix short sprintf buffer in /proc/keys show function
2016-10-26 14:01 [PATCH 0/3] KEYS: Fixes David Howells
@ 2016-10-26 14:01 ` David Howells
2016-10-26 14:02 ` [PATCH 2/3] KEYS: Sort out big_key initialisation David Howells
2016-10-26 14:02 ` [PATCH 3/3] security/keys: make BIG_KEYS dependent on stdrng David Howells
2 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2016-10-26 14:01 UTC (permalink / raw)
To: jmorris
Cc: linux-kernel, stable, dhowells, linux-security-module, keyrings,
Ondrej Kozina
This fixes CVE-2016-7042.
Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector
is turned on, this can cause a panic due to stack corruption.
The problem is that xbuf[] is not big enough to hold a 64-bit timeout
rendered as weeks:
(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
$2 = 30500568904943
That's 14 chars plus NUL, not 11 chars plus NUL.
Expand the buffer to 16 chars.
I think the unpatched code apparently works if the stack-protector is not
enabled because on a 32-bit machine the buffer won't be overflowed and on a
64-bit machine there's a 64-bit aligned pointer at one side and an int that
isn't checked again on the other side.
The panic incurred looks something like:
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
Call Trace:
[<ffffffff813d941f>] dump_stack+0x63/0x84
[<ffffffff811b2cb6>] panic+0xde/0x22a
[<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
[<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
[<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
[<ffffffff81350410>] ? key_validate+0x50/0x50
[<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
[<ffffffff8126b31c>] seq_read+0x2cc/0x390
[<ffffffff812b6b12>] proc_reg_read+0x42/0x70
[<ffffffff81244fc7>] __vfs_read+0x37/0x150
[<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
[<ffffffff81246156>] vfs_read+0x96/0x130
[<ffffffff81247635>] SyS_read+0x55/0xc0
[<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
Reported-by: Ondrej Kozina <okozina@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Ondrej Kozina <okozina@redhat.com>
cc: stable@vger.kernel.org
---
security/keys/proc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/proc.c b/security/keys/proc.c
index f0611a6368cd..b9f531c9e4fa 100644
--- a/security/keys/proc.c
+++ b/security/keys/proc.c
@@ -181,7 +181,7 @@ static int proc_keys_show(struct seq_file *m, void *v)
struct timespec now;
unsigned long timo;
key_ref_t key_ref, skey_ref;
- char xbuf[12];
+ char xbuf[16];
int rc;
struct keyring_search_context ctx = {
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/3] KEYS: Sort out big_key initialisation
2016-10-26 14:01 [PATCH 0/3] KEYS: Fixes David Howells
2016-10-26 14:01 ` [PATCH 1/3] KEYS: Fix short sprintf buffer in /proc/keys show function David Howells
@ 2016-10-26 14:02 ` David Howells
2016-10-26 14:02 ` [PATCH 3/3] security/keys: make BIG_KEYS dependent on stdrng David Howells
2 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2016-10-26 14:02 UTC (permalink / raw)
To: jmorris
Cc: Peter Hlavaty, Artem Savkov, linux-kernel, stable, dhowells,
linux-security-module, keyrings, Kirill Marinushkin
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
---
security/keys/big_key.c | 59 +++++++++++++++++++++++++----------------------
1 file changed, 32 insertions(+), 27 deletions(-)
diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index c0b3030b5634..f2e1ce4af15b 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>
@@ -341,44 +342,48 @@ long big_key_read(const struct key *key, char __user *buffer, size_t buflen)
*/
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_skcipher *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_skcipher = crypto_alloc_skcipher(big_key_alg_name,
- 0, CRYPTO_ALG_ASYNC);
- if (IS_ERR(big_key_skcipher)) {
- big_key_skcipher = NULL;
- ret = -EFAULT;
- goto error;
+ cipher = crypto_alloc_skcipher(big_key_alg_name, 0, CRYPTO_ALG_ASYNC);
+ if (IS_ERR(cipher)) {
+ ret = PTR_ERR(cipher);
+ pr_err("Can't alloc crypto: %d\n", ret);
+ goto error_rng;
+ }
+
+ big_key_skcipher = 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_skcipher(big_key_skcipher);
+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);
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 3/3] security/keys: make BIG_KEYS dependent on stdrng.
2016-10-26 14:01 [PATCH 0/3] KEYS: Fixes David Howells
2016-10-26 14:01 ` [PATCH 1/3] KEYS: Fix short sprintf buffer in /proc/keys show function David Howells
2016-10-26 14:02 ` [PATCH 2/3] KEYS: Sort out big_key initialisation David Howells
@ 2016-10-26 14:02 ` David Howells
2 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2016-10-26 14:02 UTC (permalink / raw)
To: jmorris
Cc: Stephan Mueller, Artem Savkov, linux-kernel, stable, dhowells,
linux-security-module, keyrings, Kirill Marinushkin
From: Artem Savkov <asavkov@redhat.com>
Since BIG_KEYS can't be compiled as module it requires one of the "stdrng"
providers to be compiled into kernel. Otherwise big_key_crypto_init() fails
on crypto_alloc_rng step and next dereference of big_key_skcipher (e.g. in
big_key_preparse()) results in a NULL pointer dereference.
Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted')
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Stephan Mueller <smueller@chronox.de>
cc: Kirill Marinushkin <k.marinushkin@gmail.com>
cc: stable@vger.kernel.org
---
security/keys/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index f826e8739023..d942c7c2bc0a 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -41,7 +41,7 @@ config BIG_KEYS
bool "Large payload keys"
depends on KEYS
depends on TMPFS
- select CRYPTO
+ depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y)
select CRYPTO_AES
select CRYPTO_ECB
select CRYPTO_RNG
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 0/3] KEYS: Fixes
@ 2017-04-19 16:11 David Howells
0 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2017-04-19 16:11 UTC (permalink / raw)
To: jmorris
Cc: dhowells, keyrings, torvalds, linux-kernel, linux-security-modules
Hi James,
Can you pass these patches onto Linus, please?
(1) Disallow keyrings whose name begins with a '.' to be joined
[CVE-2016-9604].
(2) Change the name of the dead type to ".dead" to prevent user access
[CVE-2017-6951].
(3) Fix keyctl_set_reqkey_keyring() to not leak thread keyrings
[CVE-2017-7472].
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
Tagged thusly:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
keys-fixes-20170419
David
---
David Howells (2):
KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings
KEYS: Change the name of the dead type to ".dead" to prevent user access
Eric Biggers (1):
KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings
security/keys/gc.c | 2 +-
security/keys/keyctl.c | 20 +++++++++++--------
security/keys/process_keys.c | 44 ++++++++++++++++++++++++++----------------
3 files changed, 39 insertions(+), 27 deletions(-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/3] KEYS: Fixes
2017-04-19 16:08 David Howells
@ 2017-04-19 16:10 ` David Howells
0 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2017-04-19 16:10 UTC (permalink / raw)
To: jmorris; +Cc: dhowells, keyrings, torvalds, linux-kernel
Let me try this again, this time with the correct email addresses...
David
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 0/3] KEYS: Fixes
@ 2017-04-19 16:08 David Howells
2017-04-19 16:10 ` David Howells
0 siblings, 1 reply; 13+ messages in thread
From: David Howells @ 2017-04-19 16:08 UTC (permalink / raw)
To: jmorris; +Cc: dhowells, keyrings, torvalds, linux-kernel, linux-kernel-modules
Hi James,
Can you pass these patches onto Linus, please?
(1) Disallow keyrings whose name begins with a '.' to be joined
[CVE-2016-9604].
(2) Change the name of the dead type to ".dead" to prevent user access
[CVE-2017-6951].
(3) Fix keyctl_set_reqkey_keyring() to not leak thread keyrings
[CVE-2017-7472].
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
Tagged thusly:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
keys-fixes-20170419
David
---
David Howells (2):
KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings
KEYS: Change the name of the dead type to ".dead" to prevent user access
Eric Biggers (1):
KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings
security/keys/gc.c | 2 +-
security/keys/keyctl.c | 20 +++++++++++--------
security/keys/process_keys.c | 44 ++++++++++++++++++++++++++----------------
3 files changed, 39 insertions(+), 27 deletions(-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/3] KEYS: Fixes
2017-02-09 23:55 ` David Howells
2017-02-10 1:05 ` James Morris
@ 2017-02-10 8:45 ` David Howells
1 sibling, 0 replies; 13+ messages in thread
From: David Howells @ 2017-02-10 8:45 UTC (permalink / raw)
To: James Morris; +Cc: dhowells, linux-security-module, keyrings, linux-kernel
James Morris <jmorris@namei.org> wrote:
> It works for me on a different vm with a newer version of git, which may
> be the issue (I'm using 1.7.1).
I'm using git-2.7.4
David
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/3] KEYS: Fixes
2017-02-09 17:17 [PATCH 0/3] KEYS: Fixes David Howells
2017-02-09 23:07 ` James Morris
2017-02-09 23:55 ` David Howells
@ 2017-02-10 1:07 ` James Morris
2 siblings, 0 replies; 13+ messages in thread
From: James Morris @ 2017-02-10 1:07 UTC (permalink / raw)
To: David Howells; +Cc: linux-security-module, keyrings, linux-kernel
On Thu, 9 Feb 2017, David Howells wrote:
>
> Hi James,
>
> Can you pull these patches into your next tree please? They include the
> following:
>
> (1) Fix sign-file for use with libressl.
>
> (2) Fix error production in request_master_key().
>
> (3) Explicitly zero-out secret data before freeing it in case gcc
> optimises memset() away in future.
>
Applied.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/3] KEYS: Fixes
2017-02-09 23:55 ` David Howells
@ 2017-02-10 1:05 ` James Morris
2017-02-10 8:45 ` David Howells
1 sibling, 0 replies; 13+ messages in thread
From: James Morris @ 2017-02-10 1:05 UTC (permalink / raw)
To: David Howells; +Cc: linux-security-module, keyrings, linux-kernel
On Thu, 9 Feb 2017, David Howells wrote:
> James Morris <jmorris@namei.org> wrote:
>
> > > Tagged thusly:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> > > keys-fixes-20170209
> >
> > I'm getting this:
> >
> > $ git pull
> > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git keys-fixes-20170209
> > fatal: Couldn't find remote ref keys-fixes-20170209
>
> Ummm... I can see it in the web interface for the branch:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
>
> and the tag itself:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/tag/?h=keys-fixes-20170209
It works for me on a different vm with a newer version of git, which may
be the issue (I'm using 1.7.1).
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/3] KEYS: Fixes
2017-02-09 17:17 [PATCH 0/3] KEYS: Fixes David Howells
2017-02-09 23:07 ` James Morris
@ 2017-02-09 23:55 ` David Howells
2017-02-10 1:05 ` James Morris
2017-02-10 8:45 ` David Howells
2017-02-10 1:07 ` James Morris
2 siblings, 2 replies; 13+ messages in thread
From: David Howells @ 2017-02-09 23:55 UTC (permalink / raw)
To: James Morris; +Cc: dhowells, linux-security-module, keyrings, linux-kernel
James Morris <jmorris@namei.org> wrote:
> > Tagged thusly:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> > keys-fixes-20170209
>
> I'm getting this:
>
> $ git pull
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git keys-fixes-20170209
> fatal: Couldn't find remote ref keys-fixes-20170209
Ummm... I can see it in the web interface for the branch:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
and the tag itself:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/tag/?h=keys-fixes-20170209
It works for me:
warthog>git pull git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git keys-fixes-20170209
remote: Counting objects: 17, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 17 (delta 13), reused 10 (delta 6)
Unpacking objects: 100% (17/17), done.
From git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
* tag keys-fixes-20170209 -> FETCH_HEAD
Merge made by the 'recursive' strategy.
scripts/sign-file.c | 4 +++-
security/keys/encrypted-keys/encrypted.c | 4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
David
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/3] KEYS: Fixes
2017-02-09 17:17 [PATCH 0/3] KEYS: Fixes David Howells
@ 2017-02-09 23:07 ` James Morris
2017-02-09 23:55 ` David Howells
2017-02-10 1:07 ` James Morris
2 siblings, 0 replies; 13+ messages in thread
From: James Morris @ 2017-02-09 23:07 UTC (permalink / raw)
To: David Howells; +Cc: linux-security-module, keyrings, linux-kernel
On Thu, 9 Feb 2017, David Howells wrote:
>
> Hi James,
>
> Can you pull these patches into your next tree please? They include the
> following:
>
> (1) Fix sign-file for use with libressl.
>
> (2) Fix error production in request_master_key().
>
> (3) Explicitly zero-out secret data before freeing it in case gcc
> optimises memset() away in future.
>
> I don't think there's anything urgent enough here to warrant handing
> directly to Linus.
>
> The patches can be found here also:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
>
> Tagged thusly:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> keys-fixes-20170209
I'm getting this:
$ git pull
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git keys-fixes-20170209
fatal: Couldn't find remote ref keys-fixes-20170209
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 0/3] KEYS: Fixes
@ 2017-02-09 17:17 David Howells
2017-02-09 23:07 ` James Morris
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: David Howells @ 2017-02-09 17:17 UTC (permalink / raw)
To: jmorris; +Cc: dhowells, linux-security-module, keyrings, linux-kernel
Hi James,
Can you pull these patches into your next tree please? They include the
following:
(1) Fix sign-file for use with libressl.
(2) Fix error production in request_master_key().
(3) Explicitly zero-out secret data before freeing it in case gcc
optimises memset() away in future.
I don't think there's anything urgent enough here to warrant handing
directly to Linus.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
Tagged thusly:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
keys-fixes-20170209
David
---
Dan Carpenter (2):
KEYS: Fix an error code in request_master_key()
KEYS: Use memzero_explicit() for secret data
Felix Fietkau (1):
sign-file: fix build error in sign-file.c with libressl
scripts/sign-file.c | 4 +++-
security/keys/encrypted-keys/encrypted.c | 4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-04-19 16:12 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-26 14:01 [PATCH 0/3] KEYS: Fixes David Howells
2016-10-26 14:01 ` [PATCH 1/3] KEYS: Fix short sprintf buffer in /proc/keys show function David Howells
2016-10-26 14:02 ` [PATCH 2/3] KEYS: Sort out big_key initialisation David Howells
2016-10-26 14:02 ` [PATCH 3/3] security/keys: make BIG_KEYS dependent on stdrng David Howells
2017-02-09 17:17 [PATCH 0/3] KEYS: Fixes David Howells
2017-02-09 23:07 ` James Morris
2017-02-09 23:55 ` David Howells
2017-02-10 1:05 ` James Morris
2017-02-10 8:45 ` David Howells
2017-02-10 1:07 ` James Morris
2017-04-19 16:08 David Howells
2017-04-19 16:10 ` David Howells
2017-04-19 16:11 David Howells
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).