Fix incorrect updates of uninstantiated keys crash the kernel (rhbz 1498017)

3 files changed, 396 insertions, 1 deletions

diff --git a/KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch b/KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch
new file mode 100644
index 000000000..af7478ee5
--- /dev/null
+++ b/KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch
@@ -0,0 +1,130 @@
+From 7289bfaee2a42bdb56eecab0625907c045d080ba Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Wed, 27 Sep 2017 12:50:41 -0700
+Subject: [PATCH] KEYS: don't let add_key() update an uninstantiated key
+
+Currently, add_key() will, when passed a key that already exists, call
+the key's ->update() method.  But this is heavily broken in the case
+where the key is uninstantiated because it doesn't call
+__key_instantiate_and_link().  Consequently, it doesn't do most of the
+things that are supposed to happen when the key is instantiated, such as
+setting KEY_FLAG_INSTANTIATED, clearing KEY_FLAG_USER_CONSTRUCT and
+awakening tasks waiting on it, and incrementing key->user->nikeys.
+
+It also never takes key_construction_mutex, which means that
+->instantiate() can run concurrently with ->update() on the same key.
+In the case of the "user" and "logon" key types this causes a memory
+leak, at best.  Maybe even worse, the ->update() methods of the
+"encrypted" and "trusted" key types actually just dereference a NULL
+pointer when passed an uninstantiated key.
+
+Therefore, change find_key_to_update() to return NULL if the found key
+is uninstantiated, so that add_key() replaces the key rather than
+instantiating it.  This seems to be better than fixing __key_update() to
+call __key_instantiate_and_link(), since given all the bugs noted above
+as well as that the existing behavior was undocumented and
+keyctl_instantiate() is supposed to be used instead, I doubt anyone was
+relying on the existing behavior.
+
+This patch only affects *uninstantiated* keys.  For now we still allow a
+negatively instantiated key to be updated (thereby positively
+instantiating it), although that's broken too (the next patch fixes it)
+and I'm not sure that anyone actually uses that functionality either.
+
+Here is a simple reproducer for the bug using the "encrypted" key type
+(requires CONFIG_ENCRYPTED_KEYS=y), though as noted above the bug
+pertained to more than just the "encrypted" key type:
+
+    #include <stdlib.h>
+    #include <unistd.h>
+    #include <keyutils.h>
+
+    int main(void)
+    {
+        int ringid = keyctl_join_session_keyring(NULL);
+
+        if (fork()) {
+            for (;;) {
+                const char payload[] = "update user:foo 32";
+
+                usleep(rand() % 10000);
+                add_key("encrypted", "desc", payload, sizeof(payload), ringid);
+                keyctl_clear(ringid);
+            }
+        } else {
+            for (;;)
+                request_key("encrypted", "desc", "callout_info", ringid);
+        }
+    }
+
+It causes:
+
+    BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
+    IP: encrypted_update+0xb0/0x170
+    PGD 7a178067 P4D 7a178067 PUD 77269067 PMD 0
+    PREEMPT SMP
+    CPU: 0 PID: 340 Comm: reproduce Tainted: G      D         4.14.0-rc1-00025-g428490e38b2e #796
+    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
+    task: ffff8a467a39a340 task.stack: ffffb15c40770000
+    RIP: 0010:encrypted_update+0xb0/0x170
+    RSP: 0018:ffffb15c40773de8 EFLAGS: 00010246
+    RAX: 0000000000000000 RBX: ffff8a467a275b00 RCX: 0000000000000000
+    RDX: 0000000000000005 RSI: ffff8a467a275b14 RDI: ffffffffb742f303
+    RBP: ffffb15c40773e20 R08: 0000000000000000 R09: ffff8a467a275b17
+    R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000
+    R13: 0000000000000000 R14: ffff8a4677057180 R15: ffff8a467a275b0f
+    FS:  00007f5d7fb08700(0000) GS:ffff8a467f200000(0000) knlGS:0000000000000000
+    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+    CR2: 0000000000000018 CR3: 0000000077262005 CR4: 00000000001606f0
+    Call Trace:
+     key_create_or_update+0x2bc/0x460
+     SyS_add_key+0x10c/0x1d0
+     entry_SYSCALL_64_fastpath+0x1f/0xbe
+    RIP: 0033:0x7f5d7f211259
+    RSP: 002b:00007ffed03904c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
+    RAX: ffffffffffffffda RBX: 000000003b2a7955 RCX: 00007f5d7f211259
+    RDX: 00000000004009e4 RSI: 00000000004009ff RDI: 0000000000400a04
+    RBP: 0000000068db8bad R08: 000000003b2a7955 R09: 0000000000000004
+    R10: 000000000000001a R11: 0000000000000246 R12: 0000000000400868
+    R13: 00007ffed03905d0 R14: 0000000000000000 R15: 0000000000000000
+    Code: 77 28 e8 64 34 1f 00 45 31 c0 31 c9 48 8d 55 c8 48 89 df 48 8d 75 d0 e8 ff f9 ff ff 85 c0 41 89 c4 0f 88 84 00 00 00 4c 8b 7d c8 <49> 8b 75 18 4c 89 ff e8 24 f8 ff ff 85 c0 41 89 c4 78 6d 49 8b
+    RIP: encrypted_update+0xb0/0x170 RSP: ffffb15c40773de8
+    CR2: 0000000000000018
+
+Cc: <stable@vger.kernel.org>    [v2.6.12+]
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+---
+ security/keys/keyring.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/security/keys/keyring.c b/security/keys/keyring.c
+index 4fa82a8a9c0e..129a4175760b 100644
+--- a/security/keys/keyring.c
++++ b/security/keys/keyring.c
+@@ -1056,8 +1056,8 @@ EXPORT_SYMBOL(keyring_restrict);
+  * caller must also hold a lock on the keyring semaphore.
+  *
+  * Returns a pointer to the found key with usage count incremented if
+- * successful and returns NULL if not found.  Revoked and invalidated keys are
+- * skipped over.
++ * successful and returns NULL if not found.  Revoked, invalidated, and
++ * uninstantiated keys are skipped over.  (But negative keys are not!)
+  *
+  * If successful, the possession indicator is propagated from the keyring ref
+  * to the returned key reference.
+@@ -1084,8 +1084,10 @@ key_ref_t find_key_to_update(key_ref_t keyring_ref,
+ 
+ found:
+ 	key = keyring_ptr_to_key(object);
+-	if (key->flags & ((1 << KEY_FLAG_INVALIDATED) |
+-			  (1 << KEY_FLAG_REVOKED))) {
++	if ((key->flags & ((1 << KEY_FLAG_INVALIDATED) |
++			   (1 << KEY_FLAG_REVOKED) |
++			   (1 << KEY_FLAG_INSTANTIATED))) !=
++	    (1 << KEY_FLAG_INSTANTIATED)) {
+ 		kleave(" = NULL [x]");
+ 		return NULL;
+ 	}
+-- 
+2.13.6
+
diff --git a/KEYS-fix-race-between-updating-and-finding-negative-.patch b/KEYS-fix-race-between-updating-and-finding-negative-.patch
new file mode 100644
index 000000000..e72cdaf4a
--- /dev/null
+++ b/KEYS-fix-race-between-updating-and-finding-negative-.patch
@@ -0,0 +1,258 @@
+From 4b244721c11c2f66052ceadd8ef6c48a53290e10 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Wed, 27 Sep 2017 12:50:42 -0700
+Subject: [PATCH] KEYS: fix race between updating and finding negative key
+
+In keyring_search_iterator() and in wait_for_key_construction(), we
+check whether the key has been negatively instantiated, and if so return
+the key's ->reject_error.
+
+However, no lock is held during this, and ->reject_error is in union
+with ->payload.  And it's impossible for KEY_FLAG_NEGATIVE to be updated
+atomically with respect to ->reject_error and ->payload.
+
+Most problematically, when a negative key is positively instantiated via
+__key_update() (via sys_add_key()), ->payload is initialized first, then
+KEY_FLAG_NEGATIVE is cleared.  But that means that ->reject_error can be
+observed to have a bogus value, having been overwritten with ->payload,
+while the key still appears to be "negative".  Clearing
+KEY_FLAG_NEGATIVE first wouldn't work either, since then anyone who
+accesses the payload under rcu_read_lock() rather than the key semaphore
+might observe an uninitialized ->payload.  Nor can we just always take
+the key's semaphore when checking whether the key is negative, since
+keyring searches happen under rcu_read_lock().
+
+Therefore, fix the bug by moving ->reject_error into the high bits of
+->flags so that we can read and write it atomically with respect to
+KEY_FLAG_NEGATIVE and KEY_FLAG_INSTANTIATED.
+
+This will also allow KEY_FLAG_NEGATIVE to be removed, since tests for
+KEY_FLAG_NEGATIVE can be replaced with tests for nonzero reject_error.
+But for ease of backporting this fix, that is left for a later patch.
+
+This fixes a kernel crash caused by the following program:
+
+    #include <stdlib.h>
+    #include <unistd.h>
+    #include <keyutils.h>
+
+    int main(void)
+    {
+        int ringid = keyctl_join_session_keyring(NULL);
+
+        if (fork()) {
+            for (;;) {
+                usleep(rand() % 4096);
+                add_key("user", "desc", "x", 1, ringid);
+                keyctl_clear(ringid);
+            }
+        } else {
+            for (;;)
+                request_key("user", "desc", "", ringid);
+        }
+    }
+
+Here is the crash:
+
+    BUG: unable to handle kernel paging request at fffffffffd39a6b0
+    IP: __key_link_begin+0x0/0x100
+    PGD 7a0a067 P4D 7a0a067 PUD 7a0c067 PMD 0
+    Oops: 0000 [#1] SMP
+    CPU: 1 PID: 165 Comm: keyctl_negate_r Not tainted 4.14.0-rc1 #377
+    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
+    task: ffff9791fd809140 task.stack: ffffacba402bc000
+    RIP: 0010:__key_link_begin+0x0/0x100
+    RSP: 0018:ffffacba402bfdc8 EFLAGS: 00010282
+    RAX: ffff9791fd809140 RBX: fffffffffd39a620 RCX: 0000000000000008
+    RDX: ffffacba402bfdd0 RSI: fffffffffd39a6a0 RDI: ffff9791fd810600
+    RBP: ffffacba402bfdf8 R08: 0000000000000063 R09: ffffffff94845620
+    R10: 8080808080808080 R11: 0000000000000004 R12: ffff9791fd810600
+    R13: ffff9791fd39a940 R14: fffffffffd39a6a0 R15: 0000000000000000
+    FS:  00007fbf14a90740(0000) GS:ffff9791ffd00000(0000) knlGS:0000000000000000
+    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+    CR2: fffffffffd39a6b0 CR3: 000000003b910003 CR4: 00000000003606e0
+    Call Trace:
+     ? key_link+0x28/0xb0
+     ? search_process_keyrings+0x13/0x100
+     request_key_and_link+0xcb/0x550
+     ? keyring_instantiate+0x110/0x110
+     ? key_default_cmp+0x20/0x20
+     SyS_request_key+0xc0/0x160
+     ? exit_to_usermode_loop+0x5e/0x80
+     entry_SYSCALL_64_fastpath+0x1a/0xa5
+    RIP: 0033:0x7fbf14190bb9
+    RSP: 002b:00007ffd8e4fe6c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f9
+    RAX: ffffffffffffffda RBX: 0000000036cc28fb RCX: 00007fbf14190bb9
+    RDX: 000055748b56ca4a RSI: 000055748b56ca46 RDI: 000055748b56ca4b
+    RBP: 000055748b56ca4a R08: 0000000000000001 R09: 0000000000000001
+    R10: 0000000036cc28fb R11: 0000000000000246 R12: 000055748b56c8b0
+    R13: 00007ffd8e4fe7d0 R14: 0000000000000000 R15: 0000000000000000
+    Code: c5 0f 85 69 ff ff ff 48 c7 c3 82 ff ff ff eb ab 45 31 ed e9 18 ff ff ff 85 c0 75 8d eb d2 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 <48> 83 7e 10 00 0f 84 c5 00 00 00 55 48 89 e5 41 57 41 56 41 55
+    RIP: __key_link_begin+0x0/0x100 RSP: ffffacba402bfdc8
+    CR2: fffffffffd39a6b0
+
+Fixes: 146aa8b1453b ("KEYS: Merge the type-specific data with the payload data")
+Cc: <stable@vger.kernel.org>	[v4.4+]
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+---
+ include/linux/key.h         | 12 +++++++++++-
+ security/keys/key.c         | 26 +++++++++++++++++++-------
+ security/keys/keyctl.c      |  3 +++
+ security/keys/keyring.c     |  4 ++--
+ security/keys/request_key.c | 11 +++++++----
+ 5 files changed, 42 insertions(+), 14 deletions(-)
+
+diff --git a/include/linux/key.h b/include/linux/key.h
+index e315e16b6ff8..b7b590d7c480 100644
+--- a/include/linux/key.h
++++ b/include/linux/key.h
+@@ -189,6 +189,17 @@ struct key {
+ #define KEY_FLAG_KEEP		10	/* set if key should not be removed */
+ #define KEY_FLAG_UID_KEYRING	11	/* set if key is a user or user session keyring */
+ 
++	/*
++	 * If the key is negatively instantiated, then bits 20-31 hold the error
++	 * code which should be returned when someone tries to use the key
++	 * (unless they allow negative keys).  The error code is stored as a
++	 * positive number, so it must be negated before being returned.
++	 *
++	 * Note that a key can go from negative to positive but not vice versa.
++	 */
++#define KEY_FLAGS_REJECT_ERROR_SHIFT	20
++#define KEY_FLAGS_REJECT_ERROR_MASK	0xFFF00000
++
+ 	/* the key type and key description string
+ 	 * - the desc is used to match a key against search criteria
+ 	 * - it should be a printable string
+@@ -213,7 +224,6 @@ struct key {
+ 			struct list_head name_link;
+ 			struct assoc_array keys;
+ 		};
+-		int reject_error;
+ 	};
+ 
+ 	/* This is set on a keyring to restrict the addition of a link to a key
+diff --git a/security/keys/key.c b/security/keys/key.c
+index eb914a838840..786158d3442e 100644
+--- a/security/keys/key.c
++++ b/security/keys/key.c
+@@ -401,6 +401,20 @@ int key_payload_reserve(struct key *key, size_t datalen)
+ }
+ EXPORT_SYMBOL(key_payload_reserve);
+ 
++static void mark_key_instantiated(struct key *key, unsigned int reject_error)
++{
++	unsigned long old, new;
++
++	do {
++		old = READ_ONCE(key->flags);
++		new = (old & ~((1 << KEY_FLAG_NEGATIVE) |
++			       KEY_FLAGS_REJECT_ERROR_MASK)) |
++		      (1 << KEY_FLAG_INSTANTIATED) |
++		      (reject_error ? (1 << KEY_FLAG_NEGATIVE) : 0) |
++		      (reject_error << KEY_FLAGS_REJECT_ERROR_SHIFT);
++	} while (cmpxchg_release(&key->flags, old, new) != old);
++}
++
+ /*
+  * Instantiate a key and link it into the target keyring atomically.  Must be
+  * called with the target keyring's semaphore writelocked.  The target key's
+@@ -431,7 +445,7 @@ static int __key_instantiate_and_link(struct key *key,
+ 		if (ret == 0) {
+ 			/* mark the key as being instantiated */
+ 			atomic_inc(&key->user->nikeys);
+-			set_bit(KEY_FLAG_INSTANTIATED, &key->flags);
++			mark_key_instantiated(key, 0);
+ 
+ 			if (test_and_clear_bit(KEY_FLAG_USER_CONSTRUCT, &key->flags))
+ 				awaken = 1;
+@@ -580,10 +594,8 @@ int key_reject_and_link(struct key *key,
+ 	if (!test_bit(KEY_FLAG_INSTANTIATED, &key->flags)) {
+ 		/* mark the key as being negatively instantiated */
+ 		atomic_inc(&key->user->nikeys);
+-		key->reject_error = -error;
+-		smp_wmb();
+-		set_bit(KEY_FLAG_NEGATIVE, &key->flags);
+-		set_bit(KEY_FLAG_INSTANTIATED, &key->flags);
++		mark_key_instantiated(key, error);
++
+ 		now = current_kernel_time();
+ 		key->expiry = now.tv_sec + timeout;
+ 		key_schedule_gc(key->expiry + key_gc_delay);
+@@ -753,7 +765,7 @@ static inline key_ref_t __key_update(key_ref_t key_ref,
+ 	ret = key->type->update(key, prep);
+ 	if (ret == 0)
+ 		/* updating a negative key instantiates it */
+-		clear_bit(KEY_FLAG_NEGATIVE, &key->flags);
++		mark_key_instantiated(key, 0);
+ 
+ 	up_write(&key->sem);
+ 
+@@ -987,7 +999,7 @@ int key_update(key_ref_t key_ref, const void *payload, size_t plen)
+ 	ret = key->type->update(key, &prep);
+ 	if (ret == 0)
+ 		/* updating a negative key instantiates it */
+-		clear_bit(KEY_FLAG_NEGATIVE, &key->flags);
++		mark_key_instantiated(key, 0);
+ 
+ 	up_write(&key->sem);
+ 
+diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
+index 365ff85d7e27..19a09e121089 100644
+--- a/security/keys/keyctl.c
++++ b/security/keys/keyctl.c
+@@ -1223,6 +1223,9 @@ long keyctl_reject_key(key_serial_t id, unsigned timeout, unsigned error,
+ 	    error == ERESTART_RESTARTBLOCK)
+ 		return -EINVAL;
+ 
++	BUILD_BUG_ON(MAX_ERRNO > (KEY_FLAGS_REJECT_ERROR_MASK >>
++				  KEY_FLAGS_REJECT_ERROR_SHIFT));
++
+ 	/* the appropriate instantiation authorisation key must have been
+ 	 * assumed before calling this */
+ 	ret = -EPERM;
+diff --git a/security/keys/keyring.c b/security/keys/keyring.c
+index 129a4175760b..e54ad0ed7aa4 100644
+--- a/security/keys/keyring.c
++++ b/security/keys/keyring.c
+@@ -598,8 +598,8 @@ static int keyring_search_iterator(const void *object, void *iterator_data)
+ 	if (ctx->flags & KEYRING_SEARCH_DO_STATE_CHECK) {
+ 		/* we set a different error code if we pass a negative key */
+ 		if (kflags & (1 << KEY_FLAG_NEGATIVE)) {
+-			smp_rmb();
+-			ctx->result = ERR_PTR(key->reject_error);
++			ctx->result = ERR_PTR(-(int)(kflags >>
++						KEY_FLAGS_REJECT_ERROR_SHIFT));
+ 			kleave(" = %d [neg]", ctx->skipped_ret);
+ 			goto skipped;
+ 		}
+diff --git a/security/keys/request_key.c b/security/keys/request_key.c
+index 63e63a42db3c..0aab68344837 100644
+--- a/security/keys/request_key.c
++++ b/security/keys/request_key.c
+@@ -590,15 +590,18 @@ struct key *request_key_and_link(struct key_type *type,
+ int wait_for_key_construction(struct key *key, bool intr)
+ {
+ 	int ret;
++	unsigned long flags;
+ 
+ 	ret = wait_on_bit(&key->flags, KEY_FLAG_USER_CONSTRUCT,
+ 			  intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE);
+ 	if (ret)
+ 		return -ERESTARTSYS;
+-	if (test_bit(KEY_FLAG_NEGATIVE, &key->flags)) {
+-		smp_rmb();
+-		return key->reject_error;
+-	}
++
++	/* Pairs with RELEASE in mark_key_instantiated() */
++	flags = smp_load_acquire(&key->flags);
++	if (flags & (1 << KEY_FLAG_NEGATIVE))
++		return -(int)(flags >> KEY_FLAGS_REJECT_ERROR_SHIFT);
++
+ 	return key_validate(key);
+ }
+ EXPORT_SYMBOL(wait_for_key_construction);
+-- 
+2.13.6
+
diff --git a/kernel.spec b/kernel.spec
index 2c98eb8ea..a5e79e121 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -42,7 +42,7 @@ Summary: The Linux kernel
 # For non-released -rc kernels, this will be appended after the rcX and
 # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
 #
-%global baserelease 1
+%global baserelease 2
 %global fedora_build %{baserelease}
 
 # base_sublevel is the kernel version we're starting with and patching
@@ -636,6 +636,10 @@ Patch332: arm64-socionext-96b-enablement.patch
 # CVE-2017-7477 rhbz 1445207 1445208
 Patch502: CVE-2017-7477.patch
 
+# rhbz 1498016 1498017
+Patch503: KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch
+Patch504: KEYS-fix-race-between-updating-and-finding-negative-.patch
+
 # 600 - Patches for improved Bay and Cherry Trail device support
 # Below patches are submitted upstream, awaiting review / merging
 Patch601: 0001-Input-gpio_keys-Allow-suppression-of-input-events-fo.patch
@@ -2202,6 +2206,9 @@ fi
 #
 #
 %changelog
+* Wed Oct 11 2017 Jeremy Cline <jeremy@jcline.org>
+- Fix incorrect updates of uninstantiated keys crash the kernel (rhbz 1498017)
+
 * Wed Oct 11 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.14.0-0.rc4.git2.1
 - Linux v4.14-rc4-77-g56ae414e9d27