Skip to content

L
linux
Switch branch/tag
  1. 25 Jan, 2016 6 commits
    • Yevgeny Pats's avatar
      KEYS: Fix keyring ref leak in join_session_keyring() · 6849cd97
      Yevgeny Pats authored 
      commit 23567fd0 upstream.

This fixes CVE-2016-0728.

If a thread is asked to join as a session keyring the keyring that's already
set as its session, we leak a keyring reference.

This can be tested with the following program:

	#include <stddef.h>
	#include <stdio.h>
	#include <sys/types.h>
	#include <keyutils.h>

	int main(int argc, const char *argv[])
	{
		int i = 0;
		key_serial_t serial;

		serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
				"leaked-keyring");
		if (serial < 0) {
			perror("keyctl");
			return -1;
		}

		if (keyctl(KEYCTL_SETPERM, serial,
			   KEY_POS_ALL | KEY_USR_ALL) < 0) {
			perror("keyctl");
			return -1;
		}

		for (i = 0; i < 100; i++) {
			serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
					"leaked-keyring");
			if (serial < 0) {
				perror("keyctl");
				return -1;
			}
		}

		return 0;
	}

If, after the program has run, there something like the following line in
/proc/keys:

3f3d898f I--Q---   100 perm 3f3f0000     0     0 keyring   leaked-keyring: empty

with a usage count of 100 * the number of times the program has been run,
then the kernel is malfunctioning.  If leaked-keyring has zero usages or
has been garbage collected, then the problem is fixed.
Reported-by: default avatarYevgeny Pats <yevgeny@perception-point.io>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Acked-by: default avatarDon Zickus <dzickus@redhat.com>
Acked-by: default avatarPrarit Bhargava <prarit@redhat.com>
Acked-by: default avatarJarod Wilson <jarod@redhat.com>
Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6849cd97
    • David Howells's avatar
      KEYS: Fix race between read and revoke · 2d783600
      David Howells authored 
      commit b4a1b4f5 upstream.

This fixes CVE-2015-7550.

There's a race between keyctl_read() and keyctl_revoke().  If the revoke
happens between keyctl_read() checking the validity of a key and the key's
semaphore being taken, then the key type read method will see a revoked key.

This causes a problem for the user-defined key type because it assumes in
its read method that there will always be a payload in a non-revoked key
and doesn't check for a NULL pointer.

Fix this by making keyctl_read() check the validity of a key after taking
semaphore instead of before.

I think the bug was introduced with the original keyrings code.

This was discovered by a multithreaded test program generated by syzkaller
(http://github.com/google/syzkaller).  Here's a cleaned up version:

	#include <sys/types.h>
	#include <keyutils.h>
	#include <pthread.h>
	void *thr0(void *arg)
	{
		key_serial_t key = (unsigned long)arg;
		keyctl_revoke(key);
		return 0;
	}
	void *thr1(void *arg)
	{
		key_serial_t key = (unsigned long)arg;
		char buffer[16];
		keyctl_read(key, buffer, 16);
		return 0;
	}
	int main()
	{
		key_serial_t key = add_key("user", "%", "foo", 3, KEY_SPEC_USER_KEYRING);
		pthread_t th[5];
		pthread_create(&th[0], 0, thr0, (void *)(unsigned long)key);
		pthread_create(&th[1], 0, thr1, (void *)(unsigned long)key);
		pthread_create(&th[2], 0, thr0, (void *)(unsigned long)key);
		pthread_create(&th[3], 0, thr1, (void *)(unsigned long)key);
		pthread_join(th[0], 0);
		pthread_join(th[1], 0);
		pthread_join(th[2], 0);
		pthread_join(th[3], 0);
		return 0;
	}

Build as:

	cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread

Run as:

	while keyctl-race; do :; done

as it may need several iterations to crash the kernel.  The crash can be
summarised as:

	BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
	IP: [<ffffffff81279b08>] user_read+0x56/0xa3
	...
	Call Trace:
	 [<ffffffff81276aa9>] keyctl_read_key+0xb6/0xd7
	 [<ffffffff81277815>] SyS_keyctl+0x83/0xe0
	 [<ffffffff815dbb97>] entry_SYSCALL_64_fastpath+0x12/0x6f
Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2d783600
    • Adrien Vergé's avatar
      USB: quirks: Fix another ELAN touchscreen · 43d44427
      Adrien Vergé authored 
      commit df36c5be upstream.

Like other buggy models that had their fixes [1], the touchscreen with
id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
quirk. Otherwise, it fails to respond, blocks the boot for a random
amount of time and pollutes dmesg with:

[ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd
[ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2889.502005] usb 1-5: can't read configurations, error -71
[ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd
[ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2891.783443] usb 1-5: can't read configurations, error -71

[1]: See commits c68929f7, 876af5d4, d7499475, a32c99e7 and dc703ec2.
Tested-by: default avatarAdrien Vergé <adrienverge@gmail.com>
Signed-off-by: default avatarAdrien Vergé <adrienverge@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Oliver Neukum <ONeukum@suse.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      43d44427
    • Karl Heiss's avatar
      sctp: Prevent soft lockup when sctp_accept() is called during a timeout event · 6b1a4c84
      Karl Heiss authored 
      commit 635682a1 upstream.

A case can occur when sctp_accept() is called by the user during
a heartbeat timeout event after the 4-way handshake.  Since
sctp_assoc_migrate() changes both assoc->base.sk and assoc->ep, the
bh_sock_lock in sctp_generate_heartbeat_event() will be taken with
the listening socket but released with the new association socket.
The result is a deadlock on any future attempts to take the listening
socket lock.

Note that this race can occur with other SCTP timeouts that take
the bh_lock_sock() in the event sctp_accept() is called.

 BUG: soft lockup - CPU#9 stuck for 67s! [swapper:0]
 ...
 RIP: 0010:[<ffffffff8152d48e>]  [<ffffffff8152d48e>] _spin_lock+0x1e/0x30
 RSP: 0018:ffff880028323b20  EFLAGS: 00000206
 RAX: 0000000000000002 RBX: ffff880028323b20 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: ffff880028323be0 RDI: ffff8804632c4b48
 RBP: ffffffff8100bb93 R08: 0000000000000000 R09: 0000000000000000
 R10: ffff880610662280 R11: 0000000000000100 R12: ffff880028323aa0
 R13: ffff8804383c3880 R14: ffff880028323a90 R15: ffffffff81534225
 FS:  0000000000000000(0000) GS:ffff880028320000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
 CR2: 00000000006df528 CR3: 0000000001a85000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process swapper (pid: 0, threadinfo ffff880616b70000, task ffff880616b6cab0)
 Stack:
 ffff880028323c40 ffffffffa01c2582 ffff880614cfb020 0000000000000000
 <d> 0100000000000000 00000014383a6c44 ffff8804383c3880 ffff880614e93c00
 <d> ffff880614e93c00 0000000000000000 ffff8804632c4b00 ffff8804383c38b8
 Call Trace:
 <IRQ>
 [<ffffffffa01c2582>] ? sctp_rcv+0x492/0xa10 [sctp]
 [<ffffffff8148c559>] ? nf_iterate+0x69/0xb0
 [<ffffffff814974a0>] ? ip_local_deliver_finish+0x0/0x2d0
 [<ffffffff8148c716>] ? nf_hook_slow+0x76/0x120
 [<ffffffff814974a0>] ? ip_local_deliver_finish+0x0/0x2d0
 [<ffffffff8149757d>] ? ip_local_deliver_finish+0xdd/0x2d0
 [<ffffffff81497808>] ? ip_local_deliver+0x98/0xa0
 [<ffffffff81496ccd>] ? ip_rcv_finish+0x12d/0x440
 [<ffffffff81497255>] ? ip_rcv+0x275/0x350
 [<ffffffff8145cfeb>] ? __netif_receive_skb+0x4ab/0x750
 ...

With lockdep debugging:

 =====================================
 [ BUG: bad unlock balance detected! ]
 -------------------------------------
 CslRx/12087 is trying to release lock (slock-AF_INET) at:
 [<ffffffffa01bcae0>] sctp_generate_timeout_event+0x40/0xe0 [sctp]
 but there are no more locks to release!

 other info that might help us debug this:
 2 locks held by CslRx/12087:
 #0:  (&asoc->timers[i]){+.-...}, at: [<ffffffff8108ce1f>] run_timer_softirq+0x16f/0x3e0
 #1:  (slock-AF_INET){+.-...}, at: [<ffffffffa01bcac3>] sctp_generate_timeout_event+0x23/0xe0 [sctp]

Ensure the socket taken is also the same one that is released by
saving a copy of the socket before entering the timeout event
critical section.
Signed-off-by: default avatarKarl Heiss <kheiss@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6b1a4c84
    • Finn Thain's avatar
      m68k/mac: Make SCC reset work more reliably · 6415eac8
      Finn Thain authored 
      commit 56931d73 upstream.

For SCC initialization we cannot assume that the control register is in
the correct state to accept a register pointer. So first read from the
control register in order to "sync" up.
Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Oliver Neukum <ONeukum@suse.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6415eac8
    • Geert Uytterhoeven's avatar
      m68k/mm: Check for mm != NULL in do_page_fault() debug code · fbe21cee
      Geert Uytterhoeven authored 
      commit 4e25c0e9 upstream.

When DEBUG is enabled, do_page_fault() may dereference a NULL pointer,
causing recursive bus errors.
Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Oliver Neukum <ONeukum@suse.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      fbe21cee
  3. 19 Jan, 2016 2 commits
  5. 15 Jan, 2016 1 commit
  7. 13 Jan, 2016 1 commit
    • Rusty Russell's avatar
      module: remove MODULE_GENERIC_TABLE · 1bf7e534
      Rusty Russell authored 
      commit cff26a51 upstream.

MODULE_DEVICE_TABLE() calles MODULE_GENERIC_TABLE(); make it do the
work directly.  This also removes a wart introduced in the last patch,
where the alias is defined to be an unknown struct type "struct
type##__##name##_device_id" instead of "struct type##_device_id" (it's
an extern so GCC doesn't care, but it's wrong).

The other user of MODULE_GENERIC_TABLE (ISAPNP_CARD_TABLE) is unused,
so delete it.

Bryan: gcc v3.3.2 cares
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
Cc: Bryan Kadzban <bryan@kadzban.net>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1bf7e534
  9. 11 Jan, 2016 4 commits
  11. 09 Jan, 2016 10 commits
  13. 05 Jan, 2016 16 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7