1. 25 Jan, 2016 10 commits
    • Ouyang Zhaowei (Charles)'s avatar
      x86/xen: don't reset vcpu_info on a cancelled suspend · 81e78751
      Ouyang Zhaowei (Charles) authored
      commit 6a1f5137 upstream.
      
      On a cancelled suspend the vcpu_info location does not change (it's
      still in the per-cpu area registered by xen_vcpu_setup()).  So do not
      call xen_hvm_init_shared_info() which would make the kernel think its
      back in the shared info.  With the wrong vcpu_info, events cannot be
      received and the domain will hang after a cancelled suspend.
      Signed-off-by: default avatarCharles Ouyang <ouyangzhaowei@huawei.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      81e78751
    • Boris Ostrovsky's avatar
      xen/gntdev: Grant maps should not be subject to NUMA balancing · b25820cd
      Boris Ostrovsky authored
      commit 9c17d965 upstream.
      
      Doing so will cause the grant to be unmapped and then, during
      fault handling, the fault to be mistakenly treated as NUMA hint
      fault.
      
      In addition, even if those maps could partcipate in NUMA
      balancing, it wouldn't provide any benefit since we are unable
      to determine physical page's node (even if/when VNUMA is
      implemented).
      
      Marking grant maps' VMAs as VM_IO will exclude them from being
      part of NUMA balancing.
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b25820cd
    • Dmitry V. Levin's avatar
      x86/signal: Fix restart_syscall number for x32 tasks · ee5c3e7f
      Dmitry V. Levin authored
      commit 22eab110 upstream.
      
      When restarting a syscall with regs->ax == -ERESTART_RESTARTBLOCK,
      regs->ax is assigned to a restart_syscall number.  For x32 tasks, this
      syscall number must have __X32_SYSCALL_BIT set, otherwise it will be
      an x86_64 syscall number instead of a valid x32 syscall number. This
      issue has been there since the introduction of x32.
      
      Reported-by: strace/tests/restart_syscall.test
      Reported-and-tested-by: default avatarElvira Khabirova <lineprinter0@gmail.com>
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Cc: Elvira Khabirova <lineprinter0@gmail.com>
      Link: http://lkml.kernel.org/r/20151130215436.GA25996@altlinux.orgSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ee5c3e7f
    • Eric Dumazet's avatar
      udp: properly support MSG_PEEK with truncated buffers · c3bfbecb
      Eric Dumazet authored
      commit 197c949e upstream.
      
      Backport of this upstream commit into stable kernels :
      89c22d8c ("net: Fix skb csum races when peeking")
      exposed a bug in udp stack vs MSG_PEEK support, when user provides
      a buffer smaller than skb payload.
      
      In this case,
      skb_copy_and_csum_datagram_iovec(skb, sizeof(struct udphdr),
                                       msg->msg_iov);
      returns -EFAULT.
      
      This bug does not happen in upstream kernels since Al Viro did a great
      job to replace this into :
      skb_copy_and_csum_datagram_msg(skb, sizeof(struct udphdr), msg);
      This variant is safe vs short buffers.
      
      For the time being, instead reverting Herbert Xu patch and add back
      skb->ip_summed invalid changes, simply store the result of
      udp_lib_checksum_complete() so that we avoid computing the checksum a
      second time, and avoid the problematic
      skb_copy_and_csum_datagram_iovec() call.
      
      This patch can be applied on recent kernels as it avoids a double
      checksumming, then backported to stable kernels as a bug fix.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      c3bfbecb
    • 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
  2. 19 Jan, 2016 2 commits
  3. 15 Jan, 2016 1 commit
  4. 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
  5. 11 Jan, 2016 4 commits
  6. 09 Jan, 2016 10 commits
  7. 05 Jan, 2016 12 commits