[linux] 01/02: KEYS: potential uninitialized variable (CVE-2016-4470)

debian-kernel at lists.debian.org debian-kernel at lists.debian.org
Fri Jun 24 21:51:48 UTC 2016


This is an automated email from the git hooks/post-receive script.

benh pushed a commit to branch jessie-security
in repository linux.

commit d7574c1564b1eef2270ce5da2969105d61572bd5
Author: Ben Hutchings <ben at decadent.org.uk>
Date:   Fri Jun 24 22:06:14 2016 +0200

    KEYS: potential uninitialized variable (CVE-2016-4470)
---
 debian/changelog                                   |  1 +
 .../keys-potential-uninitialized-variable.patch    | 86 ++++++++++++++++++++++
 debian/patches/series                              |  1 +
 3 files changed, 88 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 688d827..f4b7b18 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -41,6 +41,7 @@ linux (3.16.7-ckt25-2+deb8u1) UNRELEASED; urgency=medium
   * net: fix a kernel infoleak in x25 module (CVE-2016-4580)
   * IB/security: Restrict use of the write() interface (CVE-2016-4565)
   * ppp: take reference on channels netns (CVE-2016-4805)
+  * KEYS: potential uninitialized variable (CVE-2016-4470)
 
   [ Salvatore Bonaccorso ]
   * [x86] USB: usbip: fix potential out-of-bounds write (CVE-2016-3955)
diff --git a/debian/patches/bugfix/all/keys-potential-uninitialized-variable.patch b/debian/patches/bugfix/all/keys-potential-uninitialized-variable.patch
new file mode 100644
index 0000000..e58c076
--- /dev/null
+++ b/debian/patches/bugfix/all/keys-potential-uninitialized-variable.patch
@@ -0,0 +1,86 @@
+From: Dan Carpenter <dan.carpenter at oracle.com>
+Date: Thu, 16 Jun 2016 15:48:57 +0100
+Subject: KEYS: potential uninitialized variable
+Origin: https://git.kernel.org/linus/38327424b40bcebe2de92d07312c89360ac9229a
+
+If __key_link_begin() failed then "edit" would be uninitialized.  I've
+added a check to fix that.
+
+This allows a random user to crash the kernel, though it's quite
+difficult to achieve.  There are three ways it can be done as the user
+would have to cause an error to occur in __key_link():
+
+ (1) Cause the kernel to run out of memory.  In practice, this is difficult
+     to achieve without ENOMEM cropping up elsewhere and aborting the
+     attempt.
+
+ (2) Revoke the destination keyring between the keyring ID being looked up
+     and it being tested for revocation.  In practice, this is difficult to
+     time correctly because the KEYCTL_REJECT function can only be used
+     from the request-key upcall process.  Further, users can only make use
+     of what's in /sbin/request-key.conf, though this does including a
+     rejection debugging test - which means that the destination keyring
+     has to be the caller's session keyring in practice.
+
+ (3) Have just enough key quota available to create a key, a new session
+     keyring for the upcall and a link in the session keyring, but not then
+     sufficient quota to create a link in the nominated destination keyring
+     so that it fails with EDQUOT.
+
+The bug can be triggered using option (3) above using something like the
+following:
+
+	echo 80 >/proc/sys/kernel/keys/root_maxbytes
+	keyctl request2 user debug:fred negate @t
+
+The above sets the quota to something much lower (80) to make the bug
+easier to trigger, but this is dependent on the system.  Note also that
+the name of the keyring created contains a random number that may be
+between 1 and 10 characters in size, so may throw the test off by
+changing the amount of quota used.
+
+Assuming the failure occurs, something like the following will be seen:
+
+	kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
+	------------[ cut here ]------------
+	kernel BUG at ../mm/slab.c:2821!
+	...
+	RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
+	RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
+	RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
+	RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
+	RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
+	R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
+	R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
+	...
+	Call Trace:
+	  kfree+0xde/0x1bc
+	  assoc_array_cancel_edit+0x1f/0x36
+	  __key_link_end+0x55/0x63
+	  key_reject_and_link+0x124/0x155
+	  keyctl_reject_key+0xb6/0xe0
+	  keyctl_negate_key+0x10/0x12
+	  SyS_keyctl+0x9f/0xe7
+	  do_syscall_64+0x63/0x13a
+	  entry_SYSCALL64_slow_path+0x25/0x25
+
+Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()')
+Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>
+Signed-off-by: David Howells <dhowells at redhat.com>
+cc: stable at vger.kernel.org
+Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
+---
+ security/keys/key.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/security/keys/key.c
++++ b/security/keys/key.c
+@@ -575,7 +575,7 @@ int key_reject_and_link(struct key *key,
+ 
+ 	mutex_unlock(&key_construction_mutex);
+ 
+-	if (keyring)
++	if (keyring && link_ret == 0)
+ 		__key_link_end(keyring, &key->index_key, edit);
+ 
+ 	/* wake up anyone waiting for a key to be constructed */
diff --git a/debian/patches/series b/debian/patches/series
index 9766e20..d64a5fa 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -702,3 +702,4 @@ bugfix/all/net-fix-infoleak-in-rtnetlink.patch
 bugfix/all/net-fix-a-kernel-infoleak-in-x25-module.patch
 bugfix/all/ib-security-restrict-use-of-the-write-interface.patch
 bugfix/all/ppp-take-reference-on-channels-netns.patch
+bugfix/all/keys-potential-uninitialized-variable.patch

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/kernel/linux.git



More information about the Kernel-svn-changes mailing list