main/linux-grsec: security fixes (CVE-2015-7872, CVE-2015-7885)

4 files changed, 215 insertions, 1 deletions

diff --git a/main/linux-grsec/APKBUILD b/main/linux-grsec/APKBUILD
index 7fc883b8b..0445aee04 100644
--- a/main/linux-grsec/APKBUILD
+++ b/main/linux-grsec/APKBUILD
@@ -7,7 +7,7 @@ case $pkgver in
 *.*.*)	_kernver=${pkgver%.*};;
 *.*)	_kernver=${pkgver};;
 esac
-pkgrel=1
+pkgrel=2
 pkgdesc="Linux kernel with grsecurity"
 url=http://grsecurity.net
 depends="mkinitfs"
@@ -26,9 +26,12 @@ source="http://ftp.kernel.org/pub/linux/kernel/v4.x/linux-$_kernver.tar.xz
 	validate-vj-compression-slot-parameters-completely.patch
 	kvm-svm-unconditionally-intercept-#db.patch
 	vivid-osd-fix-info-leak-in-ioctl.patch
+	staging-dgnc-fix-info-leak-in-ioctl.patch
 	net-add-validation-socket-syscall-protocol-argument.patch
 	pptp-verify-sockaddr_len.patch
 	ovl-fix-permission-checking-for-setattr.patch
+	keys-fix-race-between-destruction-and-finding-keyring-by-name.patch
+	keys-fixes.patch
 
 	config-grsec.x86
 	config-grsec.x86_64
@@ -219,9 +222,12 @@ b0337a2a9abed17c37eae5db332522d2  fix-spi-nor-namespace-clash.patch
 9b150b8017a25fb6c9e9e29b1f1e791f  validate-vj-compression-slot-parameters-completely.patch
 c02b7d642341d3b82cff47d801813254  kvm-svm-unconditionally-intercept-#db.patch
 b52be7e646d3572687e4d26d4291233e  vivid-osd-fix-info-leak-in-ioctl.patch
+6c48221dbad6928f2b9f6c1f521c5844  staging-dgnc-fix-info-leak-in-ioctl.patch
 730439fc2751795dc00f1fb3ec810b12  net-add-validation-socket-syscall-protocol-argument.patch
 e4590e034252bb838220d2bedc19be2e  pptp-verify-sockaddr_len.patch
 5f27a173424a42db509b46372c200e85  ovl-fix-permission-checking-for-setattr.patch
+0526ef5b0cb5c8b697ab8fcd337d303e  keys-fix-race-between-destruction-and-finding-keyring-by-name.patch
+370b4498d0dc52eb8a85a23a5973bebf  keys-fixes.patch
 f8eec4df8fcd64f5f4810a2840e8cee7  config-grsec.x86
 dcccfa220ed2b2041971492d1dfa9440  config-grsec.x86_64
 cf395fd923139074f3f1095c29a63e2b  config-grsec.armhf
@@ -237,9 +243,12 @@ a92b81dbd4fa4fbee28cebad93b0bd623820c809e98e8841151842341b9626eb  grsec-4.1.15-3
 d2670dc40c47de365d36ba1e1bbef0ea3e6381f5d4c38e88a4c5db2eb4383925  validate-vj-compression-slot-parameters-completely.patch
 eb787ea2e4637708475569f7498c1ef0fa5e4e80ae22df5c5f44092615f86ebd  kvm-svm-unconditionally-intercept-#db.patch
 4070f46003fb5e1a16474f682da78d989809272a7aa209f794caa8d0b941e2c0  vivid-osd-fix-info-leak-in-ioctl.patch
+144886917b2c5ff880c4beb11ca8743b98ea5ed49bbd10a54a98e1d76cfe23b5  staging-dgnc-fix-info-leak-in-ioctl.patch
 180af96ce8310913f6662be50ca69c9737af250ef8dd3fdefdc58bef5f55ca9e  net-add-validation-socket-syscall-protocol-argument.patch
 5d3f0311176addb6cbbe0739736962cdb3826816e5cc0384f52d34cbd7c2c2a0  pptp-verify-sockaddr_len.patch
 79fa593d628d740c7bc2b68398ab381ad978293102d1f282919ee69aeab6a17d  ovl-fix-permission-checking-for-setattr.patch
+c3a7a6d1ca5c23c98ea703c716144dc88b5bcf5052416a7ff3c766beed78d7db  keys-fix-race-between-destruction-and-finding-keyring-by-name.patch
+653bdfac4fdac0fed19b60c8ae34afe97a699bbabe0e00888584c1ef52a626e1  keys-fixes.patch
 b179db21c31861da5da8a49307994e11e6a6b83d88fb3dffcf20b369ab32f8e6  config-grsec.x86
 f2c3a2b565346baa29bdf48bab6da6fcfa1723b505237ef33a0655bf80ef2e18  config-grsec.x86_64
 b996d6fc9eb8bd453826fb9c0ae573ef42a6fff3193adf33c2bf14480924ca16  config-grsec.armhf
@@ -255,9 +264,12 @@ c737219a382206894889ddf8e807836a6fd08bb983b5e2327fae9f8427a0fa591c17f896b6e3f8da
 528604f2296bd1a67e32b465b4885ddba8ccf50925909e80cc523186ab03439c47eb5c016c133f3e3f27b0666f234f88a9c33399d7550867a448e12c73f878c2  validate-vj-compression-slot-parameters-completely.patch
 5d9628e59117b9b0e464bfdac4249663a8c46f8c0ac5f521e19bbb1d59ad3a0dc0d97de34a1f011033d31c792452e6b20a70081ec8cc208bf0671fb50017ab6c  kvm-svm-unconditionally-intercept-#db.patch
 98bd4ef55ce0b7c4b4fee638ba079555a7363f1b34bc415135bd2fcbd12957ef45d569d7bf85edcbf322638f9951e01951807279279e729bbc13bee3be5d2b45  vivid-osd-fix-info-leak-in-ioctl.patch
+51bdf43837e0bc24771b6dd67e4f5f49ae77716a49155b2b04ca17aa84a7aea65f858733795a91d8c5c3221a77c576370c0ccc7e711c32edaa87210cf55974ec  staging-dgnc-fix-info-leak-in-ioctl.patch
 d41f3b7c30d59a0fb43f877fff5a311c7fad8e12dfb51c519af368e8d1511202e6cceace3e051620a90e30f3c4b170847172764db045c9a5777663e2e9f2116c  net-add-validation-socket-syscall-protocol-argument.patch
 9454738454abee92200c7025a5b19e6870056ee71faf7e78dc10c0e7317e2d27c940ab031e2e53db856e1bea3b3fe5e32ce5aaa7c29dc833aa0f75d35bbf7a79  pptp-verify-sockaddr_len.patch
 061d58353e8d8eb83a10ae1cdfd16ff5d982ee594decd115d42f438293747b9f4ea3cb16ce242685b34d52ca57feb3b8e9f344adc425e1894f0283abe47ef355  ovl-fix-permission-checking-for-setattr.patch
+d4d65eacdac1d9baed2ddf926f09a6d66b4dc42ea40ac9b118ad69dfd8dcc06052afb742aaf906fad54d70182d2243bdc1f0649eea7754a2402fc94447d568b1  keys-fix-race-between-destruction-and-finding-keyring-by-name.patch
+2611db9cca53ac6851beb9f48e51651090e6b97a644d260671d6f4aa2b2d75ff71276b6d14d0b2e5908bc261c86fc6c2dc4bd88e093fdd74e144983c720f0a2b  keys-fixes.patch
 b31862d0998cbe72882f2db3ab9452051bb5202a3921f5f4aebb24727a187227792af88c6b6ceef8ff28ab34123d1321bb8d06656f37c844afcf566571ba8865  config-grsec.x86
 87c4c3be53f03ee6e7c4fa1853b43c506ee5d35d4c156b5030424b7712e469521898a56c0b6a4562e31ea2bca855dae7429ea9048f9d2fa8b29db2d14211d230  config-grsec.x86_64
 aecd465ceb265355ef71c213ee589cc18c7695589e3410fb8762669d5f728a7e071e1b05e3864a8c621dec870a472a0e1075b2b335fafabfe62891c7d746161d  config-grsec.armhf
diff --git a/main/linux-grsec/keys-fix-race-between-destruction-and-finding-keyring-by-name.patch b/main/linux-grsec/keys-fix-race-between-destruction-and-finding-keyring-by-name.patch
new file mode 100644
index 000000000..792296068
--- /dev/null
+++ b/main/linux-grsec/keys-fix-race-between-destruction-and-finding-keyring-by-name.patch
@@ -0,0 +1,52 @@
+From 94c4554ba07adbdde396748ee7ae01e86cf2d8d7 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Fri, 25 Sep 2015 16:30:08 +0100
+Subject: KEYS: Fix race between key destruction and finding a keyring by name
+
+There appears to be a race between:
+
+ (1) key_gc_unused_keys() which frees key->security and then calls
+     keyring_destroy() to unlink the name from the name list
+
+ (2) find_keyring_by_name() which calls key_permission(), thus accessing
+     key->security, on a key before checking to see whether the key usage is 0
+     (ie. the key is dead and might be cleaned up).
+
+Fix this by calling ->destroy() before cleaning up the core key data -
+including key->security.
+
+Reported-by: Petr Matousek <pmatouse@redhat.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+---
+ security/keys/gc.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/security/keys/gc.c b/security/keys/gc.c
+index c795237..39eac1f 100644
+--- a/security/keys/gc.c
++++ b/security/keys/gc.c
+@@ -134,6 +134,10 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
+ 		kdebug("- %u", key->serial);
+ 		key_check(key);
+ 
++		/* Throw away the key data */
++		if (key->type->destroy)
++			key->type->destroy(key);
++
+ 		security_key_free(key);
+ 
+ 		/* deal with the user's key tracking and quota */
+@@ -148,10 +152,6 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
+ 		if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags))
+ 			atomic_dec(&key->user->nikeys);
+ 
+-		/* now throw away the key memory */
+-		if (key->type->destroy)
+-			key->type->destroy(key);
+-
+ 		key_user_put(key->user);
+ 
+ 		kfree(key->description);
+-- 
+cgit v0.11.2
+
diff --git a/main/linux-grsec/keys-fixes.patch b/main/linux-grsec/keys-fixes.patch
new file mode 100644
index 000000000..8ef8a0c35
--- /dev/null
+++ b/main/linux-grsec/keys-fixes.patch
@@ -0,0 +1,117 @@
+From f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Thu, 15 Oct 2015 17:21:37 +0100
+Subject: KEYS: Fix crash when attempt to garbage collect an uninstantiated
+ keyring
+
+The following sequence of commands:
+
+    i=`keyctl add user a a @s`
+    keyctl request2 keyring foo bar @t
+    keyctl unlink $i @s
+
+tries to invoke an upcall to instantiate a keyring if one doesn't already
+exist by that name within the user's keyring set.  However, if the upcall
+fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
+other error code.  When the key is garbage collected, the key destroy
+function is called unconditionally and keyring_destroy() uses list_empty()
+on keyring->type_data.link - which is in a union with reject_error.
+Subsequently, the kernel tries to unlink the keyring from the keyring names
+list - which oopses like this:
+
+	BUG: unable to handle kernel paging request at 00000000ffffff8a
+	IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88
+	...
+	Workqueue: events key_garbage_collector
+	...
+	RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88
+	RSP: 0018:ffff88003e2f3d30  EFLAGS: 00010203
+	RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
+	RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
+	RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
+	R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
+	R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
+	...
+	CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
+	...
+	Call Trace:
+	 [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f
+	 [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351
+	 [<ffffffff8105ec9b>] process_one_work+0x28e/0x547
+	 [<ffffffff8105fd17>] worker_thread+0x26e/0x361
+	 [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8
+	 [<ffffffff810648ad>] kthread+0xf3/0xfb
+	 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
+	 [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70
+	 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
+
+Note the value in RAX.  This is a 32-bit representation of -ENOKEY.
+
+The solution is to only call ->destroy() if the key was successfully
+instantiated.
+
+Reported-by: Dmitry Vyukov <dvyukov@google.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Tested-by: Dmitry Vyukov <dvyukov@google.com>
+---
+ security/keys/gc.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/security/keys/gc.c b/security/keys/gc.c
+index 39eac1f..addf060 100644
+--- a/security/keys/gc.c
++++ b/security/keys/gc.c
+@@ -134,8 +134,10 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
+ 		kdebug("- %u", key->serial);
+ 		key_check(key);
+ 
+-		/* Throw away the key data */
+-		if (key->type->destroy)
++		/* Throw away the key data if the key is instantiated */
++		if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags) &&
++		    !test_bit(KEY_FLAG_NEGATIVE, &key->flags) &&
++		    key->type->destroy)
+ 			key->type->destroy(key);
+ 
+ 		security_key_free(key);
+-- 
+cgit v0.11.2
+
+
+From 911b79cde95c7da0ec02f48105358a36636b7a71 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Mon, 19 Oct 2015 11:20:28 +0100
+Subject: KEYS: Don't permit request_key() to construct a new keyring
+
+If request_key() is used to find a keyring, only do the search part - don't
+do the construction part if the keyring was not found by the search.  We
+don't really want keyrings in the negative instantiated state since the
+rejected/negative instantiation error value in the payload is unioned with
+keyring metadata.
+
+Now the kernel gives an error:
+
+	request_key("keyring", "#selinux,bdekeyring", "keyring", KEY_SPEC_USER_SESSION_KEYRING) = -1 EPERM (Operation not permitted)
+
+Signed-off-by: David Howells <dhowells@redhat.com>
+---
+ security/keys/request_key.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/security/keys/request_key.c b/security/keys/request_key.c
+index 486ef6f..0d62531 100644
+--- a/security/keys/request_key.c
++++ b/security/keys/request_key.c
+@@ -440,6 +440,9 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
+ 
+ 	kenter("");
+ 
++	if (ctx->index_key.type == &key_type_keyring)
++		return ERR_PTR(-EPERM);
++	
+ 	user = key_user_lookup(current_fsuid());
+ 	if (!user)
+ 		return ERR_PTR(-ENOMEM);
+-- 
+cgit v0.11.2
+
diff --git a/main/linux-grsec/staging-dgnc-fix-info-leak-in-ioctl.patch b/main/linux-grsec/staging-dgnc-fix-info-leak-in-ioctl.patch
new file mode 100644
index 000000000..c89d8d3b1
--- /dev/null
+++ b/main/linux-grsec/staging-dgnc-fix-info-leak-in-ioctl.patch
@@ -0,0 +1,33 @@
+From 4b6184336ebb5c8dc1eae7f7ab46ee608a748b05 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Salva=20Peir=C3=B3?= <speirofr@gmail.com>
+Date: Wed, 14 Oct 2015 17:48:02 +0200
+Subject: staging/dgnc: fix info leak in ioctl
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The dgnc_mgmt_ioctl() code fails to initialize the 16 _reserved bytes of
+struct digi_dinfo after the ->dinfo_nboards member. Add an explicit
+memset(0) before filling the structure to avoid the info leak.
+
+Signed-off-by: Salva Peiró <speirofr@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/dgnc/dgnc_mgmt.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c
+index 9ec3efe..518fbd5 100644
+--- a/drivers/staging/dgnc/dgnc_mgmt.c
++++ b/drivers/staging/dgnc/dgnc_mgmt.c
+@@ -110,6 +110,7 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+ 
+ 		spin_lock_irqsave(&dgnc_global_lock, flags);
+ 
++		memset(&ddi, 0, sizeof(ddi));
+ 		ddi.dinfo_nboards = dgnc_NumBoards;
+ 		sprintf(ddi.dinfo_version, "%s", DG_PART);
+ 
+-- 
+cgit v0.11.2
+