1. 26 Feb, 2017 5 commits
  2. 23 Feb, 2017 35 commits
    • Ben Hutchings's avatar
      Linux 3.2.85 · 1ed92fd6
      Ben Hutchings authored
      1ed92fd6
    • Takashi Iwai's avatar
      ALSA: pcm : Call kill_fasync() in stream lock · 5409b6c1
      Takashi Iwai authored
      commit 3aa02cb6 upstream.
      
      Currently kill_fasync() is called outside the stream lock in
      snd_pcm_period_elapsed().  This is potentially racy, since the stream
      may get released even during the irq handler is running.  Although
      snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
      guarantee that the irq handler finishes, thus the kill_fasync() call
      outside the stream spin lock may be invoked after the substream is
      detached, as recently reported by KASAN.
      
      As a quick workaround, move kill_fasync() call inside the stream
      lock.  The fasync is rarely used interface, so this shouldn't have a
      big impact from the performance POV.
      
      Ideally, we should implement some sync mechanism for the proper finish
      of stream and irq handler.  But this oneliner should suffice for most
      cases, so far.
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5409b6c1
    • Eric Dumazet's avatar
      net: avoid signed overflows for SO_{SND|RCV}BUFFORCE · c5167248
      Eric Dumazet authored
      commit b98b0bc8 upstream.
      
      CAP_NET_ADMIN users should not be allowed to set negative
      sk_sndbuf or sk_rcvbuf values, as it can lead to various memory
      corruptions, crashes, OOM...
      
      Note that before commit 82981930 ("net: cleanups in
      sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF
      and SO_RCVBUF were vulnerable.
      
      This needs to be backported to all known linux kernels.
      
      Again, many thanks to syzkaller team for discovering this gem.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c5167248
    • Al Viro's avatar
      sg_write()/bsg_write() is not fit to be called under KERNEL_DS · e30250c9
      Al Viro authored
      commit a0ac402c upstream.
      
      Both damn things interpret userland pointers embedded into the payload;
      worse, they are actually traversing those.  Leaving aside the bad
      API design, this is very much _not_ safe to call with KERNEL_DS.
      Bail out early if that happens.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e30250c9
    • Marcelo Ricardo Leitner's avatar
      sctp: validate chunk len before actually using it · ba43cdd8
      Marcelo Ricardo Leitner authored
      commit bf911e98 upstream.
      
      Andrey Konovalov reported that KASAN detected that SCTP was using a slab
      beyond the boundaries. It was caused because when handling out of the
      blue packets in function sctp_sf_ootb() it was checking the chunk len
      only after already processing the first chunk, validating only for the
      2nd and subsequent ones.
      
      The fix is to just move the check upwards so it's also validated for the
      1st chunk.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: moved code is slightly different]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ba43cdd8
    • Linus Torvalds's avatar
      Fix potential infoleak in older kernels · 0c91f32d
      Linus Torvalds authored
      Not upstream as it is not needed there.
      
      So a patch something like this might be a safe way to fix the
      potential infoleak in older kernels.
      
      THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
      it probably works. It just initializes the output variable with 0 in
      the inline asm description, instead of doing it in the exception
      handler.
      
      It will generate slightly worse code (a few unnecessary ALU
      operations), but it doesn't have any interactions with the exception
      handler implementation.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0c91f32d
    • Eric Dumazet's avatar
      tcp: take care of truncations done by sk_filter() · 1433b662
      Eric Dumazet authored
      commit ac6e7800 upstream.
      
      With syzkaller help, Marco Grassi found a bug in TCP stack,
      crashing in tcp_collapse()
      
      Root cause is that sk_filter() can truncate the incoming skb,
      but TCP stack was not really expecting this to happen.
      It probably was expecting a simple DROP or ACCEPT behavior.
      
      We first need to make sure no part of TCP header could be removed.
      Then we need to adjust TCP_SKB_CB(skb)->end_seq
      
      Many thanks to syzkaller team and Marco for giving us a reproducer.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarMarco Grassi <marco.gra@gmail.com>
      Reported-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1433b662
    • Willem de Bruijn's avatar
      dccp: limit sk_filter trim to payload · 9b2e0578
      Willem de Bruijn authored
      commit 4f0c40d9 upstream.
      
      Dccp verifies packet integrity, including length, at initial rcv in
      dccp_invalid_packet, later pulls headers in dccp_enqueue_skb.
      
      A call to sk_filter in-between can cause __skb_pull to wrap skb->len.
      skb_copy_datagram_msg interprets this as a negative value, so
      (correctly) fails with EFAULT. The negative length is reported in
      ioctl SIOCINQ or possibly in a DCCP_WARN in dccp_close.
      
      Introduce an sk_receive_skb variant that caps how small a filter
      program can trim packets, and call this in dccp with the header
      length. Excessively trimmed packets are now processed normally and
      queued for reception as 0B payloads.
      
      Fixes: 7c657876 ("[DCCP]: Initial implementation")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9b2e0578
    • Willem de Bruijn's avatar
      rose: limit sk_filter trim to payload · d0e04e04
      Willem de Bruijn authored
      commit f4979fce upstream.
      
      Sockets can have a filter program attached that drops or trims
      incoming packets based on the filter program return value.
      
      Rose requires data packets to have at least ROSE_MIN_LEN bytes. It
      verifies this on arrival in rose_route_frame and unconditionally pulls
      the bytes in rose_recvmsg. The filter can trim packets to below this
      value in-between, causing pull to fail, leaving the partial header at
      the time of skb_copy_datagram_msg.
      
      Place a lower bound on the size to which sk_filter may trim packets
      by introducing sk_filter_trim_cap and call this for rose packets.
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d0e04e04
    • Ben Hutchings's avatar
      net: Add __sock_queue_rcv_skb() · 55ea1559
      Ben Hutchings authored
      Extraxcted from commit e6afc8ac
      "udp: remove headers from UDP packets before queueing".
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      55ea1559
    • Kees Cook's avatar
      fbdev: color map copying bounds checking · 00a188b0
      Kees Cook authored
      commit 2dc705a9 upstream.
      
      Copying color maps to userspace doesn't check the value of to->start,
      which will cause kernel heap buffer OOB read due to signedness wraps.
      
      CVE-2016-8405
      
      Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: Peter Pi (@heisecode) of Trend Micro
      Cc: Min Chong <mchong@google.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      00a188b0
    • Benjamin Tissoires's avatar
      HID: core: prevent out-of-bound readings · 119e11a5
      Benjamin Tissoires authored
      commit 50220dea upstream.
      
      Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
      out-of-bound readings.
      
      The fields are allocated up to MAX_USAGE, meaning that potentially, we do
      not have enough fields to fit the incoming values.
      Add checks and silence KASAN.
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      119e11a5
    • Omar Sandoval's avatar
      block: fix use-after-free in sys_ioprio_get() · 1691990a
      Omar Sandoval authored
      commit 8ba86821 upstream.
      
      get_task_ioprio() accesses the task->io_context without holding the task
      lock and thus can race with exit_io_context(), leading to a
      use-after-free. The reproducer below hits this within a few seconds on
      my 4-core QEMU VM:
      
      #define _GNU_SOURCE
      #include <assert.h>
      #include <unistd.h>
      #include <sys/syscall.h>
      #include <sys/wait.h>
      
      int main(int argc, char **argv)
      {
      	pid_t pid, child;
      	long nproc, i;
      
      	/* ioprio_set(IOPRIO_WHO_PROCESS, 0, IOPRIO_PRIO_VALUE(IOPRIO_CLASS_IDLE, 0)); */
      	syscall(SYS_ioprio_set, 1, 0, 0x6000);
      
      	nproc = sysconf(_SC_NPROCESSORS_ONLN);
      
      	for (i = 0; i < nproc; i++) {
      		pid = fork();
      		assert(pid != -1);
      		if (pid == 0) {
      			for (;;) {
      				pid = fork();
      				assert(pid != -1);
      				if (pid == 0) {
      					_exit(0);
      				} else {
      					child = wait(NULL);
      					assert(child == pid);
      				}
      			}
      		}
      
      		pid = fork();
      		assert(pid != -1);
      		if (pid == 0) {
      			for (;;) {
      				/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
      				syscall(SYS_ioprio_get, 2, 0);
      			}
      		}
      	}
      
      	for (;;) {
      		/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
      		syscall(SYS_ioprio_get, 2, 0);
      	}
      
      	return 0;
      }
      
      This gets us KASAN dumps like this:
      
      [   35.526914] ==================================================================
      [   35.530009] BUG: KASAN: out-of-bounds in get_task_ioprio+0x7b/0x90 at addr ffff880066f34e6c
      [   35.530009] Read of size 2 by task ioprio-gpf/363
      [   35.530009] =============================================================================
      [   35.530009] BUG blkdev_ioc (Not tainted): kasan: bad access detected
      [   35.530009] -----------------------------------------------------------------------------
      
      [   35.530009] Disabling lock debugging due to kernel taint
      [   35.530009] INFO: Allocated in create_task_io_context+0x2b/0x370 age=0 cpu=0 pid=360
      [   35.530009] 	___slab_alloc+0x55d/0x5a0
      [   35.530009] 	__slab_alloc.isra.20+0x2b/0x40
      [   35.530009] 	kmem_cache_alloc_node+0x84/0x200
      [   35.530009] 	create_task_io_context+0x2b/0x370
      [   35.530009] 	get_task_io_context+0x92/0xb0
      [   35.530009] 	copy_process.part.8+0x5029/0x5660
      [   35.530009] 	_do_fork+0x155/0x7e0
      [   35.530009] 	SyS_clone+0x19/0x20
      [   35.530009] 	do_syscall_64+0x195/0x3a0
      [   35.530009] 	return_from_SYSCALL_64+0x0/0x6a
      [   35.530009] INFO: Freed in put_io_context+0xe7/0x120 age=0 cpu=0 pid=1060
      [   35.530009] 	__slab_free+0x27b/0x3d0
      [   35.530009] 	kmem_cache_free+0x1fb/0x220
      [   35.530009] 	put_io_context+0xe7/0x120
      [   35.530009] 	put_io_context_active+0x238/0x380
      [   35.530009] 	exit_io_context+0x66/0x80
      [   35.530009] 	do_exit+0x158e/0x2b90
      [   35.530009] 	do_group_exit+0xe5/0x2b0
      [   35.530009] 	SyS_exit_group+0x1d/0x20
      [   35.530009] 	entry_SYSCALL_64_fastpath+0x1a/0xa4
      [   35.530009] INFO: Slab 0xffffea00019bcd00 objects=20 used=4 fp=0xffff880066f34ff0 flags=0x1fffe0000004080
      [   35.530009] INFO: Object 0xffff880066f34e58 @offset=3672 fp=0x0000000000000001
      [   35.530009] ==================================================================
      
      Fix it by grabbing the task lock while we poke at the io_context.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1691990a
    • Peter Zijlstra's avatar
      perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race · 9eb0e01b
      Peter Zijlstra authored
      commit 321027c1 upstream.
      
      Di Shen reported a race between two concurrent sys_perf_event_open()
      calls where both try and move the same pre-existing software group
      into a hardware context.
      
      The problem is exactly that described in commit:
      
        f63a8daa ("perf: Fix event->ctx locking")
      
      ... where, while we wait for a ctx->mutex acquisition, the event->ctx
      relation can have changed under us.
      
      That very same commit failed to recognise sys_perf_event_context() as an
      external access vector to the events and thereby didn't apply the
      established locking rules correctly.
      
      So while one sys_perf_event_open() call is stuck waiting on
      mutex_lock_double(), the other (which owns said locks) moves the group
      about. So by the time the former sys_perf_event_open() acquires the
      locks, the context we've acquired is stale (and possibly dead).
      
      Apply the established locking rules as per perf_event_ctx_lock_nested()
      to the mutex_lock_double() for the 'move_group' case. This obviously means
      we need to validate state after we acquire the locks.
      
      Reported-by: Di Shen (Keen Lab)
      Tested-by: default avatarJohn Dias <joaodias@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Min Chong <mchong@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: f63a8daa ("perf: Fix event->ctx locking")
      Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.2:
       - Use ACCESS_ONCE() instead of READ_ONCE()
       - Test perf_event::group_flags instead of group_caps
       - Add the err_locked cleanup block, which we didn't need before
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9eb0e01b
    • Peter Zijlstra's avatar
      perf: Do not double free · fdf1236a
      Peter Zijlstra authored
      commit 13005627 upstream.
      
      In case of: err_file: fput(event_file), we'll end up calling
      perf_release() which in turn will free the event.
      
      Do not then free the event _again_.
      Tested-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: dvyukov@google.com
      Cc: eranian@google.com
      Cc: oleg@redhat.com
      Cc: panand@redhat.com
      Cc: sasha.levin@oracle.com
      Cc: vince@deater.net
      Link: http://lkml.kernel.org/r/20160224174947.697350349@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      fdf1236a
    • Peter Zijlstra's avatar
      perf: Fix event->ctx locking · f8ab792c
      Peter Zijlstra authored
      commit f63a8daa upstream.
      
      There have been a few reported issues wrt. the lack of locking around
      changing event->ctx. This patch tries to address those.
      
      It avoids the whole rwsem thing; and while it appears to work, please
      give it some thought in review.
      
      What I did fail at is sensible runtime checks on the use of
      event->ctx, the RCU use makes it very hard.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20150123125834.209535886@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.2:
       - We don't have perf_pmu_migrate_context()
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f8ab792c
    • Paul Bolle's avatar
      lockdep: Silence warning if CONFIG_LOCKDEP isn't set · 45b5aba2
      Paul Bolle authored
      commit 5cd3f5af upstream.
      
      Since commit c9a49628 ("nfsd:
      make client_lock per net") compiling nfs4state.o without
      CONFIG_LOCKDEP set, triggers this GCC warning:
      
          fs/nfsd/nfs4state.c: In function ‘free_client’:
          fs/nfsd/nfs4state.c:1051:19: warning: unused variable ‘nn’ [-Wunused-variable]
      
      The cause of that warning is that lockdep_assert_held() compiles
      away if CONFIG_LOCKDEP is not set. Silence this warning by using
      the argument to lockdep_assert_held() as a nop if CONFIG_LOCKDEP
      is not set.
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
      Cc: J. Bruce Fields <bfields@redhat.com>
      Link: http://lkml.kernel.org/r/1359060797.1325.33.camel@x61.thuisdomeinSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      45b5aba2
    • Michael Ellerman's avatar
      perf: Fix perf_event_for_each() to use sibling · 5cc2ccd8
      Michael Ellerman authored
      commit 724b6daa upstream.
      
      In perf_event_for_each() we call a function on an event, and then
      iterate over the siblings of the event.
      
      However we don't call the function on the siblings, we call it
      repeatedly on the original event - it seems "obvious" that we should
      be calling it with sibling as the argument.
      
      It looks like this broke in commit 75f937f2 ("Fix ctx->mutex
      vs counter->mutex inversion").
      
      The only effect of the bug is that the PERF_IOC_FLAG_GROUP parameter
      to the ioctls doesn't work.
      Signed-off-by: default avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1334109253-31329-1-git-send-email-michael@ellerman.id.auSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5cc2ccd8
    • Peter Hurley's avatar
      tty: Prevent ldisc drivers from re-using stale tty fields · 72bc3e47
      Peter Hurley authored
      commit dd42bf11 upstream.
      
      Line discipline drivers may mistakenly misuse ldisc-related fields
      when initializing. For example, a failure to initialize tty->receive_room
      in the N_GIGASET_M101 line discipline was recently found and fixed [1].
      Now, the N_X25 line discipline has been discovered accessing the previous
      line discipline's already-freed private data [2].
      
      Harden the ldisc interface against misuse by initializing revelant
      tty fields before instancing the new line discipline.
      
      [1]
          commit fd98e941
          Author: Tilman Schmidt <tilman@imap.cc>
          Date:   Tue Jul 14 00:37:13 2015 +0200
      
          isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
      
      [2] Report from Sasha Levin <sasha.levin@oracle.com>
          [  634.336761] ==================================================================
          [  634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0
          [  634.339558] Read of size 4 by task syzkaller_execu/8981
          [  634.340359] =============================================================================
          [  634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
          ...
          [  634.405018] Call Trace:
          [  634.405277] dump_stack (lib/dump_stack.c:52)
          [  634.405775] print_trailer (mm/slub.c:655)
          [  634.406361] object_err (mm/slub.c:662)
          [  634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
          [  634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
          [  634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
          [  634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
          [  634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
          [  634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
          [  634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
          [  634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
          [  634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)
      
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      72bc3e47
    • Tilman Schmidt's avatar
      isdn/gigaset: reset tty->receive_room when attaching ser_gigaset · d13dab54
      Tilman Schmidt authored
      commit fd98e941 upstream.
      
      Commit 79901317 ("n_tty: Don't flush buffer when closing ldisc"),
      first merged in kernel release 3.10, caused the following regression
      in the Gigaset M101 driver:
      
      Before that commit, when closing the N_TTY line discipline in
      preparation to switching to N_GIGASET_M101, receive_room would be
      reset to a non-zero value by the call to n_tty_flush_buffer() in
      n_tty's close method. With the removal of that call, receive_room
      might be left at zero, blocking data reception on the serial line.
      
      The present patch fixes that regression by setting receive_room
      to an appropriate value in the ldisc open method.
      
      Fixes: 79901317 ("n_tty: Don't flush buffer when closing ldisc")
      Signed-off-by: default avatarTilman Schmidt <tilman@imap.cc>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d13dab54
    • Peter Zijlstra's avatar
      perf: Fix race in swevent hash · d9670377
      Peter Zijlstra authored
      commit 12ca6ad2 upstream.
      
      There's a race on CPU unplug where we free the swevent hash array
      while it can still have events on. This will result in a
      use-after-free which is BAD.
      
      Simply do not free the hash array on unplug. This leaves the thing
      around and no use-after-free takes place.
      
      When the last swevent dies, we do a for_each_possible_cpu() iteration
      anyway to clean these up, at which time we'll free it, so no leakage
      will occur.
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Tested-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d9670377
    • Calvin Owens's avatar
      sg: Fix double-free when drives detach during SG_IO · 08f231da
      Calvin Owens authored
      commit f3951a37 upstream.
      
      In sg_common_write(), we free the block request and return -ENODEV if
      the device is detached in the middle of the SG_IO ioctl().
      
      Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we
      end up freeing rq->cmd in the already free rq object, and then free
      the object itself out from under the current user.
      
      This ends up corrupting random memory via the list_head on the rq
      object. The most common crash trace I saw is this:
      
        ------------[ cut here ]------------
        kernel BUG at block/blk-core.c:1420!
        Call Trace:
        [<ffffffff81281eab>] blk_put_request+0x5b/0x80
        [<ffffffffa0069e5b>] sg_finish_rem_req+0x6b/0x120 [sg]
        [<ffffffffa006bcb9>] sg_common_write.isra.14+0x459/0x5a0 [sg]
        [<ffffffff8125b328>] ? selinux_file_alloc_security+0x48/0x70
        [<ffffffffa006bf95>] sg_new_write.isra.17+0x195/0x2d0 [sg]
        [<ffffffffa006cef4>] sg_ioctl+0x644/0xdb0 [sg]
        [<ffffffff81170f80>] do_vfs_ioctl+0x90/0x520
        [<ffffffff81258967>] ? file_has_perm+0x97/0xb0
        [<ffffffff811714a1>] SyS_ioctl+0x91/0xb0
        [<ffffffff81602afb>] tracesys+0xdd/0xe2
          RIP [<ffffffff81281e04>] __blk_put_request+0x154/0x1a0
      
      The solution is straightforward: just set srp->rq to NULL in the
      failure branch so that sg_finish_rem_req() doesn't attempt to re-free
      it.
      
      Additionally, since sg_rq_end_io() will never be called on the object
      when this happens, we need to free memory backing ->cmd if it isn't
      embedded in the object itself.
      
      KASAN was extremely helpful in finding the root cause of this bug.
      Signed-off-by: default avatarCalvin Owens <calvinowens@fb.com>
      Acked-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      [bwh: Backported to 3.2:
       - sg_finish_rem_req() would not free srp->rq->cmd so don't do it here either
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      08f231da
    • Dan Carpenter's avatar
      media: info leak in __media_device_enum_links() · f43c8334
      Dan Carpenter authored
      commit c88e739b upstream.
      
      These structs have holes and reserved struct members which aren't
      cleared.  I've added a memset() so we don't leak stack information.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f43c8334
    • Russell King's avatar
      ARM: dma-mapping: don't allow DMA mappings to be marked executable · d05fedab
      Russell King authored
      commit 0ea1ec71 upstream.
      
      DMA mapping permissions were being derived from pgprot_kernel directly
      without using PAGE_KERNEL.  This causes them to be marked with executable
      permission, which is not what we want.  Fix this.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d05fedab
    • Eric Dumazet's avatar
      net: cleanups in sock_setsockopt() · 3e21b29f
      Eric Dumazet authored
      commit 82981930 upstream.
      
      Use min_t()/max_t() macros, reformat two comments, use !!test_bit() to
      match !!sock_flag()
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3e21b29f
    • Dan Carpenter's avatar
      ser_gigaset: return -ENOMEM on error instead of success · 3dd88dcf
      Dan Carpenter authored
      commit 93a97c50 upstream.
      
      If we can't allocate the resources in gigaset_initdriver() then we
      should return -ENOMEM instead of zero.
      
      Fixes: 2869b23e ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3dd88dcf
    • Marc Kleine-Budde's avatar
      can: raw: raw_setsockopt: limit number of can_filter that can be set · 7f5edaca
      Marc Kleine-Budde authored
      commit 332b05ca upstream.
      
      This patch adds a check to limit the number of can_filters that can be
      set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER
      are not prevented resulting in a warning.
      
      Reference: https://lkml.org/lkml/2016/12/2/230Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7f5edaca
    • Miklos Szeredi's avatar
      fuse: fix clearing suid, sgid for chown() · 6d1f19c6
      Miklos Szeredi authored
      commit c01638f5 upstream.
      
      Basically, the pjdfstests set the ownership of a file to 06555, and then
      chowns it (as root) to a new uid/gid. Prior to commit a09f99ed ("fuse:
      fix killing s[ug]id in setattr"), fuse would send down a setattr with both
      the uid/gid change and a new mode.  Now, it just sends down the uid/gid
      change.
      
      Technically this is NOTABUG, since POSIX doesn't _require_ that we clear
      these bits for a privileged process, but Linux (wisely) has done that and I
      think we don't want to change that behavior here.
      
      This is caused by the use of should_remove_suid(), which will always return
      0 when the process has CAP_FSETID.
      
      In fact we really don't need to be calling should_remove_suid() at all,
      since we've already been indicated that we should remove the suid, we just
      don't want to use a (very) stale mode for that.
      
      This patch should fix the above as well as simplify the logic.
      Reported-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: a09f99ed ("fuse: fix killing s[ug]id in setattr")
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      [bwh: Backported to 3.2: adjust context, indentation]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6d1f19c6
    • Florian Fainelli's avatar
      net: ep93xx_eth: Do not crash unloading module · f05f3a72
      Florian Fainelli authored
      commit c823abac upstream.
      
      When we unload the ep93xx_eth, whether we have opened the network
      interface or not, we will either hit a kernel paging request error, or a
      simple NULL pointer de-reference because:
      
      - if ep93xx_open has been called, we have created a valid DMA mapping
        for ep->descs, when we call ep93xx_stop, we also call
        ep93xx_free_buffers, ep->descs now has a stale value
      
      - if ep93xx_open has not been called, we have a NULL pointer for
        ep->descs, so performing any operation against that address just won't
        work
      
      Fix this by adding a NULL pointer check for ep->descs which means that
      ep93xx_free_buffers() was able to successfully tear down the descriptors
      and free the DMA cookie as well.
      
      Fixes: 1d22e05d ("[PATCH] Cirrus Logic ep93xx ethernet driver")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f05f3a72
    • Kees Cook's avatar
      net: ping: check minimum size on ICMP header length · 301cd43f
      Kees Cook authored
      commit 0eab121e upstream.
      
      Prior to commit c0371da6 ("put iov_iter into msghdr") in v3.19, there
      was no check that the iovec contained enough bytes for an ICMP header,
      and the read loop would walk across neighboring stack contents. Since the
      iov_iter conversion, bad arguments are noticed, but the returned error is
      EFAULT. Returning EINVAL is a clearer error and also solves the problem
      prior to v3.19.
      
      This was found using trinity with KASAN on v3.18:
      
      BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0
      Read of size 8 by task trinity-c2/9623
      page:ffffffbe034b9a08 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x0()
      page dumped because: kasan: bad access detected
      CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G    BU         3.18.0-dirty #15
      Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
      Call trace:
      [<ffffffc000209c98>] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90
      [<ffffffc000209e54>] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171
      [<     inline     >] __dump_stack lib/dump_stack.c:15
      [<ffffffc000f18dc4>] dump_stack+0x7c/0xd0 lib/dump_stack.c:50
      [<     inline     >] print_address_description mm/kasan/report.c:147
      [<     inline     >] kasan_report_error mm/kasan/report.c:236
      [<ffffffc000373dcc>] kasan_report+0x380/0x4b8 mm/kasan/report.c:259
      [<     inline     >] check_memory_region mm/kasan/kasan.c:264
      [<ffffffc00037352c>] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507
      [<ffffffc0005b9624>] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15
      [<     inline     >] memcpy_from_msg include/linux/skbuff.h:2667
      [<ffffffc000ddeba0>] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674
      [<ffffffc000dded30>] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714
      [<ffffffc000dc91dc>] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749
      [<     inline     >] __sock_sendmsg_nosec net/socket.c:624
      [<     inline     >] __sock_sendmsg net/socket.c:632
      [<ffffffc000cab61c>] sock_sendmsg+0x124/0x164 net/socket.c:643
      [<     inline     >] SYSC_sendto net/socket.c:1797
      [<ffffffc000cad270>] SyS_sendto+0x178/0x1d8 net/socket.c:1761
      
      CVE-2016-8399
      Reported-by: default avatarQidan He <i@flanker017.me>
      Fixes: c319b4d7 ("net: ipv4: add IPPROTO_ICMP socket kind")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: only ICMPv4 is supported]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      301cd43f
    • Michal Kubeček's avatar
      tipc: check minimum bearer MTU · 29273d45
      Michal Kubeček authored
      commit 3de81b75 upstream.
      
      Qian Zhang (张谦) reported a potential socket buffer overflow in
      tipc_msg_build() which is also known as CVE-2016-8632: due to
      insufficient checks, a buffer overflow can occur if MTU is too short for
      even tipc headers. As anyone can set device MTU in a user/net namespace,
      this issue can be abused by a regular user.
      
      As agreed in the discussion on Ben Hutchings' original patch, we should
      check the MTU at the moment a bearer is attached rather than for each
      processed packet. We also need to repeat the check when bearer MTU is
      adjusted to new device MTU. UDP case also needs a check to avoid
      overflow when calculating bearer MTU.
      
      Fixes: b97bf3fd ("[TIPC] Initial merge")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Reported-by: default avatarQian Zhang (张谦) <zhangqian-c@360.cn>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2:
       - Adjust filename, context
       - Duplicate macro definitions in bearer.h to avoid mutual inclusion
       - NETDEV_CHANGEMTU and NETDEV_CHANGEADDR cases in net notifier were combined
       - Drop changes in udp_media.c]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      29273d45
    • Philip Pettersson's avatar
      packet: fix race condition in packet_set_ring · a9aaf820
      Philip Pettersson authored
      commit 84ac7260 upstream.
      
      When packet_set_ring creates a ring buffer it will initialize a
      struct timer_list if the packet version is TPACKET_V3. This value
      can then be raced by a different thread calling setsockopt to
      set the version to TPACKET_V1 before packet_set_ring has finished.
      
      This leads to a use-after-free on a function pointer in the
      struct timer_list when the socket is closed as the previously
      initialized timer will not be deleted.
      
      The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
      changing the packet version while also taking the lock at the start
      of packet_set_ring.
      
      Fixes: f6fb8f10 ("af-packet: TPACKET_V3 flexible buffer implementation.")
      Signed-off-by: default avatarPhilip Pettersson <philip.pettersson@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a9aaf820
    • Thomas Gleixner's avatar
      locking/rtmutex: Prevent dequeue vs. unlock race · 30c11832
      Thomas Gleixner authored
      commit dbb26055 upstream.
      
      David reported a futex/rtmutex state corruption. It's caused by the
      following problem:
      
      CPU0		CPU1		CPU2
      
      l->owner=T1
      		rt_mutex_lock(l)
      		lock(l->wait_lock)
      		l->owner = T1 | HAS_WAITERS;
      		enqueue(T2)
      		boost()
      		  unlock(l->wait_lock)
      		schedule()
      
      				rt_mutex_lock(l)
      				lock(l->wait_lock)
      				l->owner = T1 | HAS_WAITERS;
      				enqueue(T3)
      				boost()
      				  unlock(l->wait_lock)
      				schedule()
      		signal(->T2)	signal(->T3)
      		lock(l->wait_lock)
      		dequeue(T2)
      		deboost()
      		  unlock(l->wait_lock)
      				lock(l->wait_lock)
      				dequeue(T3)
      				  ===> wait list is now empty
      				deboost()
      				 unlock(l->wait_lock)
      		lock(l->wait_lock)
      		fixup_rt_mutex_waiters()
      		  if (wait_list_empty(l)) {
      		    owner = l->owner & ~HAS_WAITERS;
      		    l->owner = owner
      		     ==> l->owner = T1
      		  }
      
      				lock(l->wait_lock)
      rt_mutex_unlock(l)		fixup_rt_mutex_waiters()
      				  if (wait_list_empty(l)) {
      				    owner = l->owner & ~HAS_WAITERS;
      cmpxchg(l->owner, T1, NULL)
       ===> Success (l->owner = NULL)
      				    l->owner = owner
      				     ==> l->owner = T1
      				  }
      
      That means the problem is caused by fixup_rt_mutex_waiters() which does the
      RMW to clear the waiters bit unconditionally when there are no waiters in
      the rtmutexes rbtree.
      
      This can be fatal: A concurrent unlock can release the rtmutex in the
      fastpath because the waiters bit is not set. If the cmpxchg() gets in the
      middle of the RMW operation then the previous owner, which just unlocked
      the rtmutex is set as the owner again when the write takes place after the
      successfull cmpxchg().
      
      The solution is rather trivial: verify that the owner member of the rtmutex
      has the waiters bit set before clearing it. This does not require a
      cmpxchg() or other atomic operations because the waiters bit can only be
      set and cleared with the rtmutex wait_lock held. It's also safe against the
      fast path unlock attempt. The unlock attempt via cmpxchg() will either see
      the bit set and take the slowpath or see the bit cleared and release it
      atomically in the fastpath.
      
      It's remarkable that the test program provided by David triggers on ARM64
      and MIPS64 really quick, but it refuses to reproduce on x86-64, while the
      problem exists there as well. That refusal might explain that this got not
      discovered earlier despite the bug existing from day one of the rtmutex
      implementation more than 10 years ago.
      
      Thanks to David for meticulously instrumenting the code and providing the
      information which allowed to decode this subtle problem.
      Reported-by: default avatarDavid Daney <ddaney@caviumnetworks.com>
      Tested-by: default avatarDavid Daney <david.daney@cavium.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Fixes: 23f78d4a ("[PATCH] pi-futex: rt mutex core")
      Link: http://lkml.kernel.org/r/20161130210030.351136722@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.2:
       - Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()
       - Adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      30c11832
    • Radim Krčmář's avatar
      KVM: x86: drop error recovery in em_jmp_far and em_ret_far · a0c74855
      Radim Krčmář authored
      commit 2117d539 upstream.
      
      em_jmp_far and em_ret_far assumed that setting IP can only fail in 64
      bit mode, but syzkaller proved otherwise (and SDM agrees).
      Code segment was restored upon failure, but it was left uninitialized
      outside of long mode, which could lead to a leak of host kernel stack.
      We could have fixed that by always saving and restoring the CS, but we
      take a simpler approach and just break any guest that manages to fail
      as the error recovery is error-prone and modern CPUs don't need emulator
      for this.
      
      Found by syzkaller:
      
        WARNING: CPU: 2 PID: 3668 at arch/x86/kvm/emulate.c:2217 em_ret_far+0x428/0x480
        Kernel panic - not syncing: panic_on_warn set ...
      
        CPU: 2 PID: 3668 Comm: syz-executor Not tainted 4.9.0-rc4+ #49
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
         [...]
        Call Trace:
         [...] __dump_stack lib/dump_stack.c:15
         [...] dump_stack+0xb3/0x118 lib/dump_stack.c:51
         [...] panic+0x1b7/0x3a3 kernel/panic.c:179
         [...] __warn+0x1c4/0x1e0 kernel/panic.c:542
         [...] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
         [...] em_ret_far+0x428/0x480 arch/x86/kvm/emulate.c:2217
         [...] em_ret_far_imm+0x17/0x70 arch/x86/kvm/emulate.c:2227
         [...] x86_emulate_insn+0x87a/0x3730 arch/x86/kvm/emulate.c:5294
         [...] x86_emulate_instruction+0x520/0x1ba0 arch/x86/kvm/x86.c:5545
         [...] emulate_instruction arch/x86/include/asm/kvm_host.h:1116
         [...] complete_emulated_io arch/x86/kvm/x86.c:6870
         [...] complete_emulated_mmio+0x4e9/0x710 arch/x86/kvm/x86.c:6934
         [...] kvm_arch_vcpu_ioctl_run+0x3b7a/0x5a90 arch/x86/kvm/x86.c:6978
         [...] kvm_vcpu_ioctl+0x61e/0xdd0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2557
         [...] vfs_ioctl fs/ioctl.c:43
         [...] do_vfs_ioctl+0x18c/0x1040 fs/ioctl.c:679
         [...] SYSC_ioctl fs/ioctl.c:694
         [...] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
         [...] entry_SYSCALL_64_fastpath+0x1f/0xc2
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Fixes: d1442d85 ("KVM: x86: Handle errors when RIP is set during far jumps")
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a0c74855
    • Theodore Ts'o's avatar
      ext4: sanity check the block and cluster size at mount time · 29f07fab
      Theodore Ts'o authored
      commit 8cdf3372 upstream.
      
      If the block size or cluster size is insane, reject the mount.  This
      is important for security reasons (although we shouldn't be just
      depending on this check).
      
      Ref: http://www.securityfocus.com/archive/1/539661
      Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506Reported-by: default avatarBorislav Petkov <bp@alien8.de>
      Reported-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      29f07fab