1. 22 Jan, 2016 30 commits
  2. 21 Jan, 2016 1 commit
    • Nikolay Aleksandrov's avatar
      net: ipmr: fix static mfc/dev leaks on table destruction · 1c8df106
      Nikolay Aleksandrov authored
      commit 0e615e96 upstream.
      
      When destroying an mrt table the static mfc entries and the static
      devices are kept, which leads to devices that can never be destroyed
      (because of refcnt taken) and leaked memory, for example:
      unreferenced object 0xffff880034c144c0 (size 192):
        comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s)
        hex dump (first 32 bytes):
          98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....
          ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................
        backtrace:
          [<ffffffff815c1b9e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811ea6e0>] kmem_cache_alloc+0x190/0x300
          [<ffffffff815931cb>] ip_mroute_setsockopt+0x5cb/0x910
          [<ffffffff8153d575>] do_ip_setsockopt.isra.11+0x105/0xff0
          [<ffffffff8153e490>] ip_setsockopt+0x30/0xa0
          [<ffffffff81564e13>] raw_setsockopt+0x33/0x90
          [<ffffffff814d1e14>] sock_common_setsockopt+0x14/0x20
          [<ffffffff814d0b51>] SyS_setsockopt+0x71/0xc0
          [<ffffffff815cdbf6>] entry_SYSCALL_64_fastpath+0x16/0x7a
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      Make sure that everything is cleaned on netns destruction.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1c8df106
  3. 14 Jan, 2016 1 commit
  4. 06 Jan, 2016 1 commit
  5. 05 Jan, 2016 7 commits
    • Andrew Honig's avatar
      KVM: x86: Reload pit counters for all channels when restoring state · df21669e
      Andrew Honig authored
      commit 0185604c upstream.
      
      Currently if userspace restores the pit counters with a count of 0
      on channels 1 or 2 and the guest attempts to read the count on those
      channels, then KVM will perform a mod of 0 and crash.  This will ensure
      that 0 values are converted to 65536 as per the spec.
      
      This is CVE-2015-7513.
      Signed-off-by: default avatarAndy Honig <ahonig@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Moritz Muehlenhoff <jmm@inutil.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      df21669e
    • David Howells's avatar
      KEYS: Fix race between read and revoke · 19347875
      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 avatarKamal Mostafa <kamal@canonical.com>
      19347875
    • Rainer Weikusat's avatar
      af_unix: Revert 'lock_interruptible' in stream receive code · 5b81c907
      Rainer Weikusat authored
      [ Upstream commit 3822b5c2 ]
      
      With b3ca9b02, the AF_UNIX SOCK_STREAM
      receive code was changed from using mutex_lock(&u->readlock) to
      mutex_lock_interruptible(&u->readlock) to prevent signals from being
      delayed for an indefinite time if a thread sleeping on the mutex
      happened to be selected for handling the signal. But this was never a
      problem with the stream receive code (as opposed to its datagram
      counterpart) as that never went to sleep waiting for new messages with the
      mutex held and thus, wouldn't cause secondary readers to block on the
      mutex waiting for the sleeping primary reader. As the interruptible
      locking makes the code more complicated in exchange for no benefit,
      change it back to using mutex_lock.
      Signed-off-by: default avatarRainer Weikusat <rweikusat@mobileactivedefense.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5b81c907
    • David S. Miller's avatar
      dc1396c9
    • WANG Cong's avatar
      0b5415ac
    • Sergei Shtylyov's avatar
      sh_eth: fix kernel oops in skb_put() · 348a7be3
      Sergei Shtylyov authored
      [ Upstream commit 248be83d ]
      
      In a low memory situation the following kernel oops occurs:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000050
      pgd = 8490c000
      [00000050] *pgd=4651e831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] PREEMPT ARM
      Modules linked in:
      CPU: 0    Not tainted  (3.4-at16 #9)
      PC is at skb_put+0x10/0x98
      LR is at sh_eth_poll+0x2c8/0xa10
      pc : [<8035f780>]    lr : [<8028bf50>]    psr: 60000113
      sp : 84eb1a90  ip : 84eb1ac8  fp : 84eb1ac4
      r10: 0000003f  r9 : 000005ea  r8 : 00000000
      r7 : 00000000  r6 : 940453b0  r5 : 00030000  r4 : 9381b180
      r3 : 00000000  r2 : 00000000  r1 : 000005ea  r0 : 00000000
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c53c7d  Table: 4248c059  DAC: 00000015
      Process klogd (pid: 2046, stack limit = 0x84eb02e8)
      [...]
      
      This is  because netdev_alloc_skb() fails and 'mdp->rx_skbuff[entry]' is left
      NULL but sh_eth_rx() later  uses it without checking.  Add such check...
      Reported-by: default avatarYasushi SHOJI <yashi@atmark-techno.com>
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      348a7be3
    • Hannes Frederic Sowa's avatar
      net: add validation for the socket syscall protocol argument · 0847db0d
      Hannes Frederic Sowa authored
      [ Upstream commit 79462ad0 ]
      
      郭永刚 reported that one could simply crash the kernel as root by
      using a simple program:
      
      	int socket_fd;
      	struct sockaddr_in addr;
      	addr.sin_port = 0;
      	addr.sin_addr.s_addr = INADDR_ANY;
      	addr.sin_family = 10;
      
      	socket_fd = socket(10,3,0x40000000);
      	connect(socket_fd , &addr,16);
      
      AF_INET, AF_INET6 sockets actually only support 8-bit protocol
      identifiers. inet_sock's skc_protocol field thus is sized accordingly,
      thus larger protocol identifiers simply cut off the higher bits and
      store a zero in the protocol fields.
      
      This could lead to e.g. NULL function pointer because as a result of
      the cut off inet_num is zero and we call down to inet_autobind, which
      is NULL for raw sockets.
      
      kernel: Call Trace:
      kernel:  [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70
      kernel:  [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80
      kernel:  [<ffffffff81645069>] SYSC_connect+0xd9/0x110
      kernel:  [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80
      kernel:  [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200
      kernel:  [<ffffffff81645e0e>] SyS_connect+0xe/0x10
      kernel:  [<ffffffff81779515>] tracesys_phase2+0x84/0x89
      
      I found no particular commit which introduced this problem.
      
      CVE: CVE-2015-8543
      Cc: Cong Wang <cwang@twopensource.com>
      Reported-by: default avatar郭永刚 <guoyonggang@360.cn>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ kamal: backport to 3.13-stable: hardcoded U8_MAX value ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0847db0d