Commit 4e1c1da1 authored by Leonardo Arena's avatar Leonardo Arena

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

parent a580066b
......@@ -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
......
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
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
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
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment