1. 30 Apr, 2016 40 commits
    • Vladis Dronov's avatar
      Input: ati_remote2 - fix crashes on detecting device with invalid descriptor · ae211053
      Vladis Dronov authored
      commit 950336ba upstream.
      
      The ati_remote2 driver expects at least two interfaces with one
      endpoint each. If given malicious descriptor that specify one
      interface or no endpoints, it will crash in the probe function.
      Ensure there is at least two interfaces and one endpoint for each
      interface before using it.
      
      The full disclosure: http://seclists.org/bugtraq/2016/Mar/90Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ae211053
    • Guillaume Nault's avatar
      ppp: take reference on channels netns · 7fda126c
      Guillaume Nault authored
      commit 1f461dcd upstream.
      
      Let channels hold a reference on their network namespace.
      Some channel types, like ppp_async and ppp_synctty, can have their
      userspace controller running in a different namespace. Therefore they
      can't rely on them to preclude their netns from being removed from
      under them.
      
      ==================================================================
      BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
      addr ffff880064e217e0
      Read of size 8 by task syz-executor/11581
      =============================================================================
      BUG net_namespace (Not tainted): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
      [<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
      [<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
      [<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
      [<     inline     >] slab_alloc kernel/mm/slub.c:2574
      [<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
      [<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
      [<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
      [<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
      [<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
      [<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
      [<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
      [<     inline     >] copy_process kernel/kernel/fork.c:1274
      [<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
      [<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
      [<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
      [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
      
      INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
      [<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
      [<     inline     >] slab_free kernel/mm/slub.c:2805
      [<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
      [<     inline     >] net_free kernel/net/core/net_namespace.c:341
      [<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
      [<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
      [<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
      [<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
      [<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
      [<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
      INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
      flags=0x5fffc0000004080
      INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
      
      CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
       00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
       ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
       ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
      Call Trace:
       [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
       [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
       [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
       [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
       [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
       [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
       [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
       [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
       [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
       [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
       [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
       [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
       [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
       [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
       [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
       [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
       [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
       [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
       [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
       [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
       [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
       [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
       [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
       [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
       [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
       [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
       [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
       [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
       [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
       [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
       [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
       [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
       [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
       [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
       [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
       [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
       [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
       [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
       [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
       [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
       [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
      Memory state around the buggy address:
       ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: 273ec51d ("net: ppp_generic - introduce net-namespace functionality v2")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Reviewed-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7fda126c
    • Aurelien Jacquiot's avatar
      rapidio/rionet: fix deadlock on SMP · e1962b09
      Aurelien Jacquiot authored
      commit 36915976 upstream.
      
      Fix deadlocking during concurrent receive and transmit operations on SMP
      platforms caused by the use of incorrect lock: on transmit 'tx_lock'
      spinlock should be used instead of 'lock' which is used for receive
      operation.
      
      This fix is applicable to kernel versions starting from v2.15.
      Signed-off-by: default avatarAurelien Jacquiot <a-jacquiot@ti.com>
      Signed-off-by: default avatarAlexandre Bounine <alexandre.bounine@idt.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Andre van Herk <andre.van.herk@prodrive-technologies.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e1962b09
    • Jann Horn's avatar
      fs/coredump: prevent fsuid=0 dumps into user-controlled directories · b1bf6857
      Jann Horn authored
      commit 378c6520 upstream.
      
      This commit fixes the following security hole affecting systems where
      all of the following conditions are fulfilled:
      
       - The fs.suid_dumpable sysctl is set to 2.
       - The kernel.core_pattern sysctl's value starts with "/". (Systems
         where kernel.core_pattern starts with "|/" are not affected.)
       - Unprivileged user namespace creation is permitted. (This is
         true on Linux >=3.8, but some distributions disallow it by
         default using a distro patch.)
      
      Under these conditions, if a program executes under secure exec rules,
      causing it to run with the SUID_DUMP_ROOT flag, then unshares its user
      namespace, changes its root directory and crashes, the coredump will be
      written using fsuid=0 and a path derived from kernel.core_pattern - but
      this path is interpreted relative to the root directory of the process,
      allowing the attacker to control where a coredump will be written with
      root privileges.
      
      To fix the security issue, always interpret core_pattern for dumps that
      are written under SUID_DUMP_ROOT relative to the root directory of init.
      Signed-off-by: default avatarJann Horn <jann@thejh.net>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.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, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b1bf6857
    • Dan Carpenter's avatar
      ethernet: micrel: fix some error codes · df79c015
      Dan Carpenter authored
      commit 3af0d554 upstream.
      
      There were two issues here:
      1) dma_mapping_error() return true/false but we want to return -ENOMEM
      2) If dmaengine_prep_slave_sg() failed then "err" wasn't set but
         presumably that should be -ENOMEM as well.
      
      I changed the success path to "return 0;" instead of "return ret;" for
      clarity.
      
      Fixes: 94fe8c68 ('ks8842: Support DMA when accessed via timberdale')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      df79c015
    • Rabin Vincent's avatar
      splice: handle zero nr_pages in splice_to_pipe() · f84eda3a
      Rabin Vincent authored
      commit d6785d91 upstream.
      
      Running the following command:
      
       busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null
      
      with any tracing enabled pretty very quickly leads to various NULL
      pointer dereferences and VM BUG_ON()s, such as these:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
       IP: [<ffffffff8119df6c>] generic_pipe_buf_release+0xc/0x40
       Call Trace:
        [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
        [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
        [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
        [<ffffffff81196869>] do_sendfile+0x199/0x380
        [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
        [<ffffffff8192cbee>] entry_SYSCALL_64_fastpath+0x12/0x6d
      
       page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0)
       kernel BUG at include/linux/mm.h:367!
       invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       RIP: [<ffffffff8119df9c>] generic_pipe_buf_release+0x3c/0x40
       Call Trace:
        [<ffffffff811c48a3>] splice_direct_to_actor+0x143/0x1e0
        [<ffffffff811c42e0>] ? generic_pipe_buf_nosteal+0x10/0x10
        [<ffffffff811c49cf>] do_splice_direct+0x8f/0xb0
        [<ffffffff81196869>] do_sendfile+0x199/0x380
        [<ffffffff81197600>] SyS_sendfile64+0x90/0xa0
        [<ffffffff8192cd1e>] tracesys_phase2+0x84/0x89
      
      (busybox's cat uses sendfile(2), unlike the coreutils version)
      
      This is because tracing_splice_read_pipe() can call splice_to_pipe()
      with spd->nr_pages == 0.  spd_pages underflows in splice_to_pipe() and
      we fill the page pointers and the other fields of the pipe_buffers with
      garbage.
      
      All other callers of splice_to_pipe() avoid calling it when nr_pages ==
      0, and we could make tracing_splice_read_pipe() do that too, but it
      seems reasonable to have splice_to_page() handle this condition
      gracefully.
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f84eda3a
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix crash from reading trace_pipe with sendfile · 1719bf67
      Steven Rostedt (Red Hat) authored
      commit a29054d9 upstream.
      
      If tracing contains data and the trace_pipe file is read with sendfile(),
      then it can trigger a NULL pointer dereference and various BUG_ON within the
      VM code.
      
      There's a patch to fix this in the splice_to_pipe() code, but it's also a
      good idea to not let that happen from trace_pipe either.
      
      Link: http://lkml.kernel.org/r/1457641146-9068-1-git-send-email-rabin@rab.inReported-by: default avatarRabin Vincent <rabin.vincent@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1719bf67
    • Arnd Bergmann's avatar
      lpfc: fix misleading indentation · 567d4fb4
      Arnd Bergmann authored
      commit aeb6641f upstream.
      
      gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array()
      call in lpfc_online(), which clearly doesn't look right:
      
      drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online':
      drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
         lpfc_destroy_vport_work_array(phba, vports);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not
        if (vports != NULL)
        ^~
      
      Looking at the patch that introduced this code, it's clear that the
      behavior is correct and the indentation is wrong.
      
      This fixes the indentation and adds curly braces around the previous
      if() block for clarity, as that is most likely what caused the code
      to be misindented in the first place.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 549e55cd ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list")
      Reviewed-by: default avatarSebastian Herbszt <herbszt@gmx.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      567d4fb4
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Have preempt(irqs)off trace preempt disabled functions · 9e1128ec
      Steven Rostedt (Red Hat) authored
      commit cb86e053 upstream.
      
      Joel Fernandes reported that the function tracing of preempt disabled
      sections was not being reported when running either the preemptirqsoff or
      preemptoff tracers. This was due to the fact that the function tracer
      callback for those tracers checked if irqs were disabled before tracing. But
      this fails when we want to trace preempt off locations as well.
      
      Joel explained that he wanted to see funcitons where interrupts are enabled
      but preemption was disabled. The expected output he wanted:
      
         <...>-2265    1d.h1 3419us : preempt_count_sub <-irq_exit
         <...>-2265    1d..1 3419us : __do_softirq <-irq_exit
         <...>-2265    1d..1 3419us : msecs_to_jiffies <-__do_softirq
         <...>-2265    1d..1 3420us : irqtime_account_irq <-__do_softirq
         <...>-2265    1d..1 3420us : __local_bh_disable_ip <-__do_softirq
         <...>-2265    1..s1 3421us : run_timer_softirq <-__do_softirq
         <...>-2265    1..s1 3421us : hrtimer_run_pending <-run_timer_softirq
         <...>-2265    1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq
         <...>-2265    1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq
         <...>-2265    1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq
         <...>-2265    1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq
         <...>-2265    1..s1 3423us : rcu_bh_qs <-__do_softirq
         <...>-2265    1d.s1 3423us : irqtime_account_irq <-__do_softirq
         <...>-2265    1d.s1 3423us : __local_bh_enable <-__do_softirq
      
      There's a comment saying that the irq disabled check is because there's a
      possible race that tracing_cpu may be set when the function is executed. But
      I don't remember that race. For now, I added a check for preemption being
      enabled too to not record the function, as there would be no race if that
      was the case. I need to re-investigate this, as I'm now thinking that the
      tracing_cpu will always be correct. But no harm in keeping the check for
      now, except for the slight performance hit.
      
      Link: http://lkml.kernel.org/r/1457770386-88717-1-git-send-email-agnel.joel@gmail.com
      
      Fixes: 5e6d2b9c "tracing: Use one prologue for the preempt irqs off tracer function tracers"
      Cc: stable@vget.kernel.org # 2.6.37+
      Reported-by: default avatarJoel Fernandes <agnel.joel@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9e1128ec
    • Oliver Neukum's avatar
      USB: cdc-acm: more sanity checking · c50eccdc
      Oliver Neukum authored
      commit 8835ba4a upstream.
      
      An attack has become available which pretends to be a quirky
      device circumventing normal sanity checks and crashes the kernel
      by an insufficient number of interfaces. This patch adds a check
      to the code path for quirky devices.
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c50eccdc
    • Oliver Neukum's avatar
      USB: usb_driver_claim_interface: add sanity checking · 79a575e8
      Oliver Neukum authored
      commit 0b818e39 upstream.
      
      Attacks that trick drivers into passing a NULL pointer
      to usb_driver_claim_interface() using forged descriptors are
      known. This thwarts them by sanity checking.
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.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>
      79a575e8
    • Josh Boyer's avatar
      USB: iowarrior: fix oops with malicious USB descriptors · e0dbd4b2
      Josh Boyer authored
      commit 4ec0ef3a upstream.
      
      The iowarrior driver expects at least one valid endpoint.  If given
      malicious descriptors that specify 0 for the number of endpoints,
      it will crash in the probe function.  Ensure there is at least
      one endpoint on the interface before using it.
      
      The full report of this issue can be found here:
      http://seclists.org/bugtraq/2016/Mar/87Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e0dbd4b2
    • Benjamin Tissoires's avatar
      Input: synaptics - handle spurious release of trackstick buttons, again · c3814d37
      Benjamin Tissoires authored
      commit 82be788c upstream.
      
      Looks like the fimware 8.2 still has the extra buttons spurious release
      bug.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c3814d37
    • Shaohua Li's avatar
      raid10: include bio_end_io_list in nr_queued to prevent freeze_array hang · 33a3e89a
      Shaohua Li authored
      commit 23ddba80 upstream.
      
      This is the raid10 counterpart of the bug fixed by Nate
      (raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang)
      
      Fixes: 95af587e(md/raid10: ensure device failure recorded before write request returns)
      Cc: Nate Dailey <nate.dailey@stratus.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      33a3e89a
    • Nate Dailey's avatar
      raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang · 11266d29
      Nate Dailey authored
      commit ccfc7bf1 upstream.
      
      If raid1d is handling a mix of read and write errors, handle_read_error's
      call to freeze_array can get stuck.
      
      This can happen because, though the bio_end_io_list is initially drained,
      writes can be added to it via handle_write_finished as the retry_list
      is processed. These writes contribute to nr_pending but are not included
      in nr_queued.
      
      If a later entry on the retry_list triggers a call to handle_read_error,
      freeze array hangs waiting for nr_pending == nr_queued+extra. The writes
      on the bio_end_io_list aren't included in nr_queued so the condition will
      never be satisfied.
      
      To prevent the hang, include bio_end_io_list writes in nr_queued.
      
      There's probably a better way to handle decrementing nr_queued, but this
      seemed like the safest way to avoid breaking surrounding code.
      
      I'm happy to supply the script I used to repro this hang.
      
      Fixes: 55ce74d4(md/raid1: ensure device failure recorded before write request returns.)
      Signed-off-by: default avatarNate Dailey <nate.dailey@stratus.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      11266d29
    • Andy Lutomirski's avatar
      x86/iopl: Fix iopl capability check on Xen PV · 64731eb9
      Andy Lutomirski authored
      commit c29016cf upstream.
      
      iopl(3) is supposed to work if iopl is already 3, even if
      unprivileged.  This didn't work right on Xen PV.  Fix it.
      Reviewewd-by: default avatarJan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Andrew Cooper <andrew.cooper3@citrix.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.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>
      64731eb9
    • Andy Lutomirski's avatar
      x86/iopl/64: Properly context-switch IOPL on Xen PV · 880ee9d2
      Andy Lutomirski authored
      commit b7a58459 upstream.
      
      On Xen PV, regs->flags doesn't reliably reflect IOPL and the
      exit-to-userspace code doesn't change IOPL.  We need to context
      switch it manually.
      
      I'm doing this without going through paravirt because this is
      specific to Xen PV.  After the dust settles, we can merge this with
      the 32-bit code, tidy up the iopl syscall implementation, and remove
      the set_iopl pvop entirely.
      
      Fixes XSA-171.
      Reviewewd-by: default avatarJan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Andrew Cooper <andrew.cooper3@citrix.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.2:
       - Use xen_pv_domain() directly as X86_FEATURE_XENPV is not defined
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      880ee9d2
    • Guillaume Nault's avatar
      ppp: ensure file->private_data can't be overridden · e4391ae1
      Guillaume Nault authored
      commit e8e56ffd upstream.
      
      Locking ppp_mutex must be done before dereferencing file->private_data,
      otherwise it could be modified before ppp_unattached_ioctl() takes the
      lock. This could lead ppp_unattached_ioctl() to override ->private_data,
      thus leaking reference to the ppp_file previously pointed to.
      
      v2: lock all ppp_ioctl() instead of just checking private_data in
          ppp_unattached_ioctl(), to avoid ambiguous behaviour.
      
      Fixes: f3ff8a4d ("ppp: push BKL down into the driver")
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e4391ae1
    • J. Bruce Fields's avatar
      nfsd: fix deadlock secinfo+readdir compound · 2ec876e3
      J. Bruce Fields authored
      commit 2f6fc056 upstream.
      
      nfsd_lookup_dentry exits with the parent filehandle locked.  fh_put also
      unlocks if necessary (nfsd filehandle locking is probably too lenient),
      so it gets unlocked eventually, but if the following op in the compound
      needs to lock it again, we can deadlock.
      
      A fuzzer ran into this; normal clients don't send a secinfo followed by
      a readdir in the same compound.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2ec876e3
    • Takashi Iwai's avatar
      ALSA: usb-audio: Add sanity checks for endpoint accesses · c0e9921c
      Takashi Iwai authored
      commit 447d6275 upstream.
      
      Add some sanity check codes before actually accessing the endpoint via
      get_endpoint() in order to avoid the invalid access through a
      malformed USB descriptor.  Mostly just checking bNumEndpoints, but in
      one place (snd_microii_spdif_default_get()), the validity of iface and
      altsetting index is checked as well.
      
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [bwh: Backported to 3.2: drop changes to code we don't have]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c0e9921c
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk() · 8e5c3482
      Takashi Iwai authored
      commit 0f886ca1 upstream.
      
      create_fixed_stream_quirk() may cause a NULL-pointer dereference by
      accessing the non-existing endpoint when a USB device with a malformed
      USB descriptor is used.
      
      This patch avoids it simply by adding a sanity check of bNumEndpoints
      before the accesses.
      
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [bwh: Backported to 3.2:
       - There's no altsd variable
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8e5c3482
    • Arnd Bergmann's avatar
      ath9k: fix buffer overrun for ar9287 · 1b8363d0
      Arnd Bergmann authored
      commit 83d6f1f1 upstream.
      
      Code that was added back in 2.6.38 has an obvious overflow
      when accessing a static array, and at the time it was added
      only a code comment was put in front of it as a reminder
      to have it reviewed properly.
      
      This has not happened, but gcc-6 now points to the specific
      overflow:
      
      drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
      drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
           maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
                         ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
      
      It turns out that the correct array length exists in the local
      'intercepts' variable of this function, so we can just use that
      instead of hardcoding '4', so this patch changes all three
      instances to use that variable. The other two instances were
      already correct, but it's more consistent this way.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 940cd2c1 ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1b8363d0
    • Arnaldo Carvalho de Melo's avatar
      net: Fix use after free in the recvmmsg exit path · 61934d09
      Arnaldo Carvalho de Melo authored
      commit 34b88a68 upstream.
      
      The syzkaller fuzzer hit the following use-after-free:
      
        Call Trace:
         [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
         [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
         [<     inline     >] SYSC_recvmmsg net/socket.c:2281
         [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
         [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
        arch/x86/entry/entry_64.S:185
      
      And, as Dmitry rightly assessed, that is because we can drop the
      reference and then touch it when the underlying recvmsg calls return
      some packets and then hit an error, which will make recvmmsg to set
      sock->sk->sk_err, oops, fix it.
      Reported-and-Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Fixes: a2e27255 ("net: Introduce recvmmsg socket syscall")
      http://lkml.kernel.org/r/20160122211644.GC2470@redhat.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      61934d09
    • Josh Boyer's avatar
      Input: powermate - fix oops with malicious USB descriptors · 615fd7f1
      Josh Boyer authored
      commit 9c6ba456 upstream.
      
      The powermate driver expects at least one valid USB endpoint in its
      probe function.  If given malicious descriptors that specify 0 for
      the number of endpoints, it will crash.  Validate the number of
      endpoints on the interface before using them.
      
      The full report for this issue can be found here:
      http://seclists.org/bugtraq/2016/Mar/85Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      615fd7f1
    • Geert Uytterhoeven's avatar
      rtc: vr41xx: Wire up alarm_irq_enable · b303809d
      Geert Uytterhoeven authored
      commit a25f4a95 upstream.
      
      drivers/rtc/rtc-vr41xx.c:229: warning: ‘vr41xx_rtc_alarm_irq_enable’ defined but not used
      
      Apparently the conversion to alarm_irq_enable forgot to wire up the
      callback.
      
      Fixes: 16380c15 ("RTC: Convert rtc drivers to use the alarm_irq_enable method")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b303809d
    • Vittorio Gambaletta (VittGam)'s avatar
      ALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41. · 3e074035
      Vittorio Gambaletta (VittGam) authored
      commit 4061db03 upstream.
      
      The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41
      will often fail, so add a quirk entry to fix it.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3e074035
    • DingXiang's avatar
      dm snapshot: disallow the COW and origin devices from being identical · 9d4ac2d1
      DingXiang authored
      commit 4df2bf46 upstream.
      
      Otherwise loading a "snapshot" table using the same device for the
      origin and COW devices, e.g.:
      
      echo "0 20971520 snapshot 253:3 253:3 P 8" | dmsetup create snap
      
      will trigger:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
      [ 1958.979934] IP: [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
      [ 1958.989655] PGD 0
      [ 1958.991903] Oops: 0000 [#1] SMP
      ...
      [ 1959.059647] CPU: 9 PID: 3556 Comm: dmsetup Tainted: G          IO    4.5.0-rc5.snitm+ #150
      ...
      [ 1959.083517] task: ffff8800b9660c80 ti: ffff88032a954000 task.ti: ffff88032a954000
      [ 1959.091865] RIP: 0010:[<ffffffffa040efba>]  [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
      [ 1959.104295] RSP: 0018:ffff88032a957b30  EFLAGS: 00010246
      [ 1959.110219] RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000000001
      [ 1959.118180] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff880329334a00
      [ 1959.126141] RBP: ffff88032a957b50 R08: 0000000000000000 R09: 0000000000000001
      [ 1959.134102] R10: 000000000000000a R11: f000000000000000 R12: ffff880330884d80
      [ 1959.142061] R13: 0000000000000008 R14: ffffc90001c13088 R15: ffff880330884d80
      [ 1959.150021] FS:  00007f8926ba3840(0000) GS:ffff880333440000(0000) knlGS:0000000000000000
      [ 1959.159047] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1959.165456] CR2: 0000000000000098 CR3: 000000032f48b000 CR4: 00000000000006e0
      [ 1959.173415] Stack:
      [ 1959.175656]  ffffc90001c13040 ffff880329334a00 ffff880330884ed0 ffff88032a957bdc
      [ 1959.183946]  ffff88032a957bb8 ffffffffa040f225 ffff880329334a30 ffff880300000000
      [ 1959.192233]  ffffffffa04133e0 ffff880329334b30 0000000830884d58 00000000569c58cf
      [ 1959.200521] Call Trace:
      [ 1959.203248]  [<ffffffffa040f225>] dm_exception_store_create+0x1d5/0x240 [dm_snapshot]
      [ 1959.211986]  [<ffffffffa040d310>] snapshot_ctr+0x140/0x630 [dm_snapshot]
      [ 1959.219469]  [<ffffffffa0005c44>] ? dm_split_args+0x64/0x150 [dm_mod]
      [ 1959.226656]  [<ffffffffa0005ea7>] dm_table_add_target+0x177/0x440 [dm_mod]
      [ 1959.234328]  [<ffffffffa0009203>] table_load+0x143/0x370 [dm_mod]
      [ 1959.241129]  [<ffffffffa00090c0>] ? retrieve_status+0x1b0/0x1b0 [dm_mod]
      [ 1959.248607]  [<ffffffffa0009e35>] ctl_ioctl+0x255/0x4d0 [dm_mod]
      [ 1959.255307]  [<ffffffff813304e2>] ? memzero_explicit+0x12/0x20
      [ 1959.261816]  [<ffffffffa000a0c3>] dm_ctl_ioctl+0x13/0x20 [dm_mod]
      [ 1959.268615]  [<ffffffff81215eb6>] do_vfs_ioctl+0xa6/0x5c0
      [ 1959.274637]  [<ffffffff81120d2f>] ? __audit_syscall_entry+0xaf/0x100
      [ 1959.281726]  [<ffffffff81003176>] ? do_audit_syscall_entry+0x66/0x70
      [ 1959.288814]  [<ffffffff81216449>] SyS_ioctl+0x79/0x90
      [ 1959.294450]  [<ffffffff8167e4ae>] entry_SYSCALL_64_fastpath+0x12/0x71
      ...
      [ 1959.323277] RIP  [<ffffffffa040efba>] dm_exception_store_set_chunk_size+0x7a/0x110 [dm_snapshot]
      [ 1959.333090]  RSP <ffff88032a957b30>
      [ 1959.336978] CR2: 0000000000000098
      [ 1959.344121] ---[ end trace b049991ccad1169e ]---
      
      Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1195899Signed-off-by: default avatarDing Xiang <dingxiang@huawei.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      [bwh: Backported to 3.2: the device path parsing code is rather different,
       but move it into dm_get_dev_t() anyway]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9d4ac2d1
    • Dmitry Tunin's avatar
      Bluetooth: btusb: Add a new AR3012 ID 13d3:3472 · dd47ac8c
      Dmitry Tunin authored
      commit 75c6aca4 upstream.
      
      T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=13d3 ProdID=3472 Rev=00.01
      C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      
      BugLink: https://bugs.launchpad.net/bugs/1552925Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dd47ac8c
    • OGAWA Hirofumi's avatar
      jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path · e2503935
      OGAWA Hirofumi authored
      commit c0a2ad9b upstream.
      
      On umount path, jbd2_journal_destroy() writes latest transaction ID
      (->j_tail_sequence) to be used at next mount.
      
      The bug is that ->j_tail_sequence is not holding latest transaction ID
      in some cases. So, at next mount, there is chance to conflict with
      remaining (not overwritten yet) transactions.
      
      	mount (id=10)
      	write transaction (id=11)
      	write transaction (id=12)
      	umount (id=10) <= the bug doesn't write latest ID
      
      	mount (id=10)
      	write transaction (id=11)
      	crash
      
      	mount
      	[recovery process]
      		transaction (id=11)
      		transaction (id=12) <= valid transaction ID, but old commit
                                             must not replay
      
      Like above, this bug become the cause of recovery failure, or FS
      corruption.
      
      So why ->j_tail_sequence doesn't point latest ID?
      
      Because if checkpoint transactions was reclaimed by memory pressure
      (i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated.
      (And another case is, __jbd2_journal_clean_checkpoint_list() is called
      with empty transaction.)
      
      So in above cases, ->j_tail_sequence is not pointing latest
      transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not
      done too.
      
      So, to fix this problem with minimum changes, this patch updates
      ->j_tail_sequence, and issue REQ_FLUSH.  (With more complex changes,
      some optimizations would be possible to avoid unnecessary REQ_FLUSH
      for example though.)
      
      BTW,
      
      	journal->j_tail_sequence =
      		++journal->j_transaction_sequence;
      
      Increment of ->j_transaction_sequence seems to be unnecessary, but
      ext3 does this.
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e2503935
    • Douglas Gilbert's avatar
      sg: fix dxferp in from_to case · 88a8579c
      Douglas Gilbert authored
      commit 5ecee0a3 upstream.
      
      One of the strange things that the original sg driver did was let the
      user provide both a data-out buffer (it followed the sg_header+cdb)
      _and_ specify a reply length greater than zero. What happened was that
      the user data-out buffer was copied into some kernel buffers and then
      the mid level was told a read type operation would take place with the
      data from the device overwriting the same kernel buffers. The user would
      then read those kernel buffers back into the user space.
      
      From what I can tell, the above action was broken by commit fad7f01e
      ("sg: set dxferp to NULL for READ with the older SG interface") in 2008
      and syzkaller found that out recently.
      
      Make sure that a user space pointer is passed through when data follows
      the sg_header structure and command.  Fix the abnormal case when a
      non-zero reply_len is also given.
      
      Fixes: fad7f01eSigned-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      88a8579c
    • Mario Kleiner's avatar
      drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards. · a8bb2012
      Mario Kleiner authored
      commit 459ee1c3 upstream.
      
      As observed on Apple iMac10,1, DCE-3.2, RV-730,
      link rate of 2.7 Ghz is not selected, because
      the args.v1.ucConfig flag setting for 2.7 Ghz
      gets overwritten by a following assignment of
      the transmitter to use.
      
      Move link rate setup a few lines down to fix this.
      In practice this didn't have any positive or
      negative effect on display setup on the tested
      iMac10,1 so i don't know if backporting to stable
      makes sense or not.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a8bb2012
    • Maurizio Lombardi's avatar
      be2iscsi: set the boot_kset pointer to NULL in case of failure · 701566be
      Maurizio Lombardi authored
      commit 84bd6499 upstream.
      
      In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
      NULL in case of failure otherwise an invalid pointer dereference may
      occur later.
      Signed-off-by: default avatarMaurizio Lombardi <mlombard@redhat.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarJitendra Bhivare <jitendra.bhivare@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      701566be
    • Bjorn Helgaas's avatar
      x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs · ac8f5acf
      Bjorn Helgaas authored
      commit b8941571 upstream.
      
      The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register
      where a BAR should be.  We don't know what the side effects of sizing the
      "BAR" would be, and we don't know what address space the "BAR" might appear
      to describe.
      
      Mark these devices as having non-compliant BARs so the PCI core doesn't
      touch them.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Tested-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ac8f5acf
    • Marco Angaroni's avatar
      ipvs: correct initial offset of Call-ID header search in SIP persistence engine · e8238ed2
      Marco Angaroni authored
      commit 7617a24f upstream.
      
      The IPVS SIP persistence engine is not able to parse the SIP header
      "Call-ID" when such header is inserted in the first positions of
      the SIP message.
      
      When IPVS is configured with "--pe sip" option, like for example:
      ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o
      some particular messages (see below for details) do not create entries
      in the connection template table, which can be listed with:
      ipvsadm -Lcn --persistent-conn
      
      Problematic SIP messages are SIP responses having "Call-ID" header
      positioned just after message first line:
      SIP/2.0 200 OK
      [Call-ID header here]
      [rest of the headers]
      
      When "Call-ID" header is positioned down (after a few other headers)
      it is correctly recognized.
      
      This is due to the data offset used in get_callid function call inside
      ip_vs_pe_sip.c file: since dptr already points to the start of the
      SIP message, the value of dataoff should be initially 0.
      Otherwise the header is searched starting from some bytes after the
      first character of the SIP message.
      
      Fixes: 758ff033 ("IPVS: sip persistence engine")
      Signed-off-by: default avatarMarco Angaroni <marcoangaroni@gmail.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e8238ed2
    • Thomas Gleixner's avatar
      sched/cputime: Fix steal time accounting vs. CPU hotplug · a41e182b
      Thomas Gleixner authored
      commit e9532e69 upstream.
      
      On CPU hotplug the steal time accounting can keep a stale rq->prev_steal_time
      value over CPU down and up. So after the CPU comes up again the delta
      calculation in steal_account_process_tick() wreckages itself due to the
      unsigned math:
      
      	 u64 steal = paravirt_steal_clock(smp_processor_id());
      
      	 steal -= this_rq()->prev_steal_time;
      
      So if steal is smaller than rq->prev_steal_time we end up with an insane large
      value which then gets added to rq->prev_steal_time, resulting in a permanent
      wreckage of the accounting. As a consequence the per CPU stats in /proc/stat
      become stale.
      
      Nice trick to tell the world how idle the system is (100%) while the CPU is
      100% busy running tasks. Though we prefer realistic numbers.
      
      None of the accounting values which use a previous value to account for
      fractions is reset at CPU hotplug time. update_rq_clock_task() has a sanity
      check for prev_irq_time and prev_steal_time_rq, but that sanity check solely
      deals with clock warps and limits the /proc/stat visible wreckage. The
      prev_time values are still wrong.
      
      Solution is simple: Reset rq->prev_*_time when the CPU is plugged in again.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Glauber Costa <glommer@parallels.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: commit 095c0aa8 "sched: adjust scheduler cpu power for stolen time"
      Fixes: commit aa483808 "sched: Remove irq time from available CPU power"
      Fixes: commit e6e6685a "KVM guest: Steal time accounting"
      Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603041539490.3686@nanosSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.2: adjust filenames]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a41e182b
    • Radim Krčmář's avatar
      KVM: i8254: change PIT discard tick policy · e2599de1
      Radim Krčmář authored
      commit 7dd0fdff upstream.
      
      Discard policy uses ack_notifiers to prevent injection of PIT interrupts
      before EOI from the last one.
      
      This patch changes the policy to always try to deliver the interrupt,
      which makes a difference when its vector is in ISR.
      Old implementation would drop the interrupt, but proposed one injects to
      IRR, like real hardware would.
      
      The old policy breaks legacy NMI watchdogs, where PIT is used through
      virtual wire (LVT0): PIT never sends an interrupt before receiving EOI,
      thus a guest deadlock with disabled interrupts will stop NMIs.
      
      Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt
      through IOAPIC.  (KVM's PIT is deeply rotten and luckily not used much
      in modern systems.)
      
      Even though there is a chance of regressions, I think we can fix the
      LVT0 NMI bug without introducing a new tick policy.
      Reported-by: default avatarYuki Shibuya <shibuya.yk@ncos.nec.co.jp>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [bwh: Backported to 3.2:
       - s/ps->reinject/ps->pit_timer.reinject/
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e2599de1
    • Oliver Neukum's avatar
      usb: hub: fix a typo in hub_port_init() leading to wrong logic · 6a1fbc07
      Oliver Neukum authored
      commit 0d5ce778 upstream.
      
      A typo of j for i led to a logic bug. To rule out future
      confusion, the variable names are made meaningful.
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.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>
      6a1fbc07
    • Michael Hennerich's avatar
      drivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors · d352582f
      Michael Hennerich authored
      commit f3df53e4 upstream.
      
      Fix RDAC read back errors caused by a typo. Value must shift by 2.
      
      Fixes: a4bd3949 ("drivers/misc/ad525x_dpot.c: new features")
      Signed-off-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d352582f
    • Mateusz Guzik's avatar
      xfs: fix two memory leaks in xfs_attr_list.c error paths · f9b3ef7e
      Mateusz Guzik authored
      commit 2e83b79b upstream.
      
      This plugs 2 trivial leaks in xfs_attr_shortform_list and
      xfs_attr3_leaf_list_int.
      Signed-off-by: default avatarMateusz Guzik <mguzik@redhat.com>
      Reviewed-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f9b3ef7e
    • J. Bruce Fields's avatar
      nfsd4: fix bad bounds checking · 49c27d2f
      J. Bruce Fields authored
      commit 4aed9c46 upstream.
      
      A number of spots in the xdr decoding follow a pattern like
      
      	n = be32_to_cpup(p++);
      	READ_BUF(n + 4);
      
      where n is a u32.  The only bounds checking is done in READ_BUF itself,
      but since it's checking (n + 4), it won't catch cases where n is very
      large, (u32)(-4) or higher.  I'm not sure exactly what the consequences
      are, but we've seen crashes soon after.
      
      Instead, just break these up into two READ_BUF()s.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      49c27d2f