Re: [PATCH] KEYS: Fix handling of stored error in a negatively instantiated user key

[David Howells]

James Morris  wrote:

> Is this triggerable by normal users?

Yes.

David
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] KEYS: Fix handling of stored error in a negatively instantiated user key

[David Howells]

If a user key gets negatively instantiated, an error code is cached in the
payload area.  A negatively instantiated key may be then be positively
instantiated by updating it with valid data.  However, the ->update key
type method must be aware that the error code may be there.

The following may be used to trigger the bug in the user key type:

keyctl request2 user user "" @u
keyctl add user user "a" @u

which manifests itself as:

BUG: unable to handle kernel paging request at ff8a
IP: [] __call_rcu.constprop.76+0x1f/0x280 
kernel/rcu/tree.c:3046
PGD 7cc30067 PUD 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
01/01/2011
task: 88003ddea700 ti: 88003dd88000 task.ti: 88003dd88000
RIP: 0010:[]  [] 
__call_rcu.constprop.76+0x1f/0x280
 [] __call_rcu.constprop.76+0x1f/0x280 
kernel/rcu/tree.c:3046
RSP: 0018:88003dd8bdb0  EFLAGS: 00010246
RAX: ff82 RBX:  RCX: 0001
RDX: 81e3fe40 RSI:  RDI: ff82
RBP: 88003dd8bde0 R08: 88007d2d2da0 R09: 
R10:  R11: 88003e8073c0 R12: ff82
R13: 88003dd8be68 R14: 88007d027600 R15: 88003ddea700
FS:  00b92880(0063) GS:88007fd0() 
knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: ff8a CR3: 7cc5f000 CR4: 06e0
Stack:
 88003dd8bdf0 81160a8a  ff82
 88003dd8be68 88007d027600 88003dd8bdf0 810a39e5
 88003dd8be20 812a31ab 88007d027600 88007d027620
Call Trace:
 [] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136
 [] user_update+0x8b/0xb0 
security/keys/user_defined.c:129
 [< inline >] __key_update security/keys/key.c:730
 [] key_create_or_update+0x291/0x440 
security/keys/key.c:908
 [< inline >] SYSC_add_key security/keys/keyctl.c:125
 [] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60
 [] entry_SYSCALL_64_fastpath+0x12/0x6a 
arch/x86/entry/entry_64.S:185

Note the error code (-ENOKEY) in EDX.

A similar bug can be tripped by:

keyctl request2 trusted user "" @u
keyctl add trusted user "a" @u

This should also affect encrypted keys - but that has to be correctly
parameterised or it will fail with EINVAL before getting to the bit that
will crashes.

Reported-by: Dmitry Vyukov 
Signed-off-by: David Howells 
Acked-by: Mimi Zohar 
---

 security/keys/encrypted-keys/encrypted.c |2 ++
 security/keys/trusted.c  |5 -
 security/keys/user_defined.c |5 -
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/security/keys/encrypted-keys/encrypted.c 
b/security/keys/encrypted-keys/encrypted.c
index 927db9f35ad6..696ccfa08d10 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -845,6 +845,8 @@ static int encrypted_update(struct key *key, struct 
key_preparsed_payload *prep)
size_t datalen = prep->datalen;
int ret = 0;
 
+   if (test_bit(KEY_FLAG_NEGATIVE, >flags))
+   return -ENOKEY;
if (datalen <= 0 || datalen > 32767 || !prep->data)
return -EINVAL;
 
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index 903dace648a1..16dec53184b6 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -1007,13 +1007,16 @@ static void trusted_rcu_free(struct rcu_head *rcu)
  */
 static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
 {
-   struct trusted_key_payload *p = key->payload.data[0];
+   struct trusted_key_payload *p;
struct trusted_key_payload *new_p;
struct trusted_key_options *new_o;
size_t datalen = prep->datalen;
char *datablob;
int ret = 0;
 
+   if (test_bit(KEY_FLAG_NEGATIVE, >flags))
+   return -ENOKEY;
+   p = key->payload.data[0];
if (!p->migratable)
return -EPERM;
if (datalen <= 0 || datalen > 32767 || !prep->data)
diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c
index 28cb30f80256..8705d79b2c6f 100644
--- a/security/keys/user_defined.c
+++ b/security/keys/user_defined.c
@@ -120,7 +120,10 @@ int user_update(struct key *key, struct 
key_preparsed_payload *prep)
 
if (ret == 0) {
/* attach the new data, displacing the old */
-   zap = key->payload.data[0];
+   if (!test_bit(KEY_FLAG_NEGATIVE, >flags))
+   zap = 

Re: [PATCH] KEYS: Fix handling of stored error in a negatively instantiated user key

[David Howells]

Hi James,

Can this be passed straight to Linus please?

Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KEYS: Fix handling of stored error in a negatively instantiated user key

[James Morris]

On Tue, 24 Nov 2015, David Howells wrote:

> Hi James,
> 
> Can this be passed straight to Linus please?

Is this triggerable by normal users?


-- 
James Morris


--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html