lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1574264230.635488352@decadent.org.uk>
Date:   Wed, 20 Nov 2019 15:38:17 +0000
From:   Ben Hutchings <ben@...adent.org.uk>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:     akpm@...ux-foundation.org, Denis Kirjanov <kda@...ux-powerpc.org>,
        "David Howells" <dhowells@...hat.com>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        "Hillf Danton" <hdanton@...a.com>,
        "Sachin Sant" <sachinp@...ux.vnet.ibm.com>
Subject: [PATCH 3.16 67/83] keys: Fix missing null pointer check in
 request_key_auth_describe()

3.16.78-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Hillf Danton <hdanton@...a.com>

commit d41a3effbb53b1bcea41e328d16a4d046a508381 upstream.

If a request_key authentication token key gets revoked, there's a window in
which request_key_auth_describe() can see it with a NULL payload - but it
makes no check for this and something like the following oops may occur:

	BUG: Kernel NULL pointer dereference at 0x00000038
	Faulting instruction address: 0xc0000000004ddf30
	Oops: Kernel access of bad area, sig: 11 [#1]
	...
	NIP [...] request_key_auth_describe+0x90/0xd0
	LR [...] request_key_auth_describe+0x54/0xd0
	Call Trace:
	[...] request_key_auth_describe+0x54/0xd0 (unreliable)
	[...] proc_keys_show+0x308/0x4c0
	[...] seq_read+0x3d0/0x540
	[...] proc_reg_read+0x90/0x110
	[...] __vfs_read+0x3c/0x70
	[...] vfs_read+0xb4/0x1b0
	[...] ksys_read+0x7c/0x130
	[...] system_call+0x5c/0x70

Fix this by checking for a NULL pointer when describing such a key.

Also make the read routine check for a NULL pointer to be on the safe side.

[DH: Modified to not take already-held rcu lock and modified to also check
 in the read routine]

Fixes: 04c567d9313e ("[PATCH] Keys: Fix race between two instantiators of a key")
Reported-by: Sachin Sant <sachinp@...ux.vnet.ibm.com>
Signed-off-by: Hillf Danton <hdanton@...a.com>
Signed-off-by: David Howells <dhowells@...hat.com>
Tested-by: Sachin Sant <sachinp@...ux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 security/keys/request_key_auth.c | 6 ++++++
 1 file changed, 6 insertions(+)

--- a/security/keys/request_key_auth.c
+++ b/security/keys/request_key_auth.c
@@ -58,6 +58,9 @@ static void request_key_auth_describe(co
 {
 	struct request_key_auth *rka = key->payload.data;
 
+	if (!rka)
+		return;
+
 	seq_puts(m, "key:");
 	seq_puts(m, key->description);
 	if (key_is_instantiated(key))
@@ -75,6 +78,9 @@ static long request_key_auth_read(const
 	size_t datalen;
 	long ret;
 
+	if (!rka)
+		return -EKEYREVOKED;
+
 	datalen = rka->callout_len;
 	ret = datalen;
 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ