1. 30 Apr, 2016 40 commits
    • Kees Cook's avatar
      x86: standardize mmap_rnd() usage · 333d0cf2
      Kees Cook authored
      commit 82168140 upstream.
      
      In preparation for splitting out ET_DYN ASLR, this refactors the use of
      mmap_rnd() to be used similarly to arm, and extracts the checking of
      PF_RANDOMIZE.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      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 context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      333d0cf2
    • Florian Westphal's avatar
      netfilter: x_tables: make sure e->next_offset covers remaining blob size · b8cea33c
      Florian Westphal authored
      commit 6e94e0cf upstream.
      
      Otherwise this function may read data beyond the ruleset blob.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b8cea33c
    • Florian Westphal's avatar
      netfilter: x_tables: validate e->target_offset early · 2fcf6767
      Florian Westphal authored
      commit bdf533de upstream.
      
      We should check that e->target_offset is sane before
      mark_source_chains gets called since it will fetch the target entry
      for loop detection.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2fcf6767
    • Helge Deller's avatar
      parisc: Unbreak handling exceptions from kernel modules · 14313e39
      Helge Deller authored
      commit 2ef4dfd9 upstream.
      
      Handling exceptions from modules never worked on parisc.
      It was just masked by the fact that exceptions from modules
      don't happen during normal use.
      
      When a module triggers an exception in get_user() we need to load the
      main kernel dp value before accessing the exception_data structure, and
      afterwards restore the original dp value of the module on exit.
      Noticed-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      14313e39
    • Helge Deller's avatar
      parisc: Fix kernel crash with reversed copy_from_user() · 2e5c1b75
      Helge Deller authored
      commit ef72f311 upstream.
      
      The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
      crash on parisc if the parameters for copy_from_user were reversed
      ("illegal reversed copy_to_user" testcase).
      
      Fix this potential crash by checking the fault handler if the faulting
      address is in the exception table.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2e5c1b75
    • Helge Deller's avatar
      parisc: Avoid function pointers for kernel exception routines · ae75f6aa
      Helge Deller authored
      commit e3893027 upstream.
      
      We want to avoid the kernel module loader to create function pointers
      for the kernel fixup routines of get_user() and put_user(). Changing
      the external reference from function type to int type fixes this.
      
      This unbreaks exception handling for get_user() and put_user() when
      called from a kernel module.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ae75f6aa
    • Martyn Welch's avatar
      USB: serial: cp210x: Adding GE Healthcare Device ID · 9499f0fd
      Martyn Welch authored
      commit cddc9434 upstream.
      
      The CP2105 is used in the GE Healthcare Remote Alarm Box, with the
      Manufacturer ID of 0x1901 and Product ID of 0x0194.
      Signed-off-by: default avatarMartyn Welch <martyn.welch@collabora.co.uk>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9499f0fd
    • Josh Boyer's avatar
      USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices · 0ab6e069
      Josh Boyer authored
      commit ea6db90e upstream.
      
      A Fedora user reports that the ftdi_sio driver works properly for the
      ICP DAS I-7561U device.  Further, the user manual for these devices
      instructs users to load the driver and add the ids using the sysfs
      interface.
      
      Add support for these in the driver directly so that the devices work
      out of the box instead of needing manual configuration.
      
      Reported-by: <thesource@mail.ru>
      Signed-off-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0ab6e069
    • Boris Ostrovsky's avatar
      xen/events: Mask a moving irq · b74d4eb2
      Boris Ostrovsky authored
      commit ff1e22e7 upstream.
      
      Moving an unmasked irq may result in irq handler being invoked on both
      source and target CPUs.
      
      With 2-level this can happen as follows:
      
      On source CPU:
              evtchn_2l_handle_events() ->
                  generic_handle_irq() ->
                      handle_edge_irq() ->
                         eoi_pirq():
                             irq_move_irq(data);
      
                             /***** WE ARE HERE *****/
      
                             if (VALID_EVTCHN(evtchn))
                                 clear_evtchn(evtchn);
      
      If at this moment target processor is handling an unrelated event in
      evtchn_2l_handle_events()'s loop it may pick up our event since target's
      cpu_evtchn_mask claims that this event belongs to it *and* the event is
      unmasked and still pending. At the same time, source CPU will continue
      executing its own handle_edge_irq().
      
      With FIFO interrupt the scenario is similar: irq_move_irq() may result
      in a EVTCHNOP_unmask hypercall which, in turn, may make the event
      pending on the target CPU.
      
      We can avoid this situation by moving and clearing the event while
      keeping event masked.
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      [bwh: Backported to 3.2:
       - Adjust filename
       - Add a suitable definition of test_and_set_mask()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b74d4eb2
    • Takashi Iwai's avatar
      ALSA: timer: Use mod_timer() for rearming the system timer · 6d834a77
      Takashi Iwai authored
      commit 4a07083e upstream.
      
      ALSA system timer backend stops the timer via del_timer() without sync
      and leaves del_timer_sync() at the close instead.  This is because of
      the restriction by the design of ALSA timer: namely, the stop callback
      may be called from the timer handler, and calling the sync shall lead
      to a hangup.  However, this also triggers a kernel BUG() when the
      timer is rearmed immediately after stopping without sync:
       kernel BUG at kernel/time/timer.c:966!
       Call Trace:
        <IRQ>
        [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
        [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
        [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
        [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
        [<ffffffff81296b72>] call_timer_fn+0x162/0x520
        [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
        [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
        ....
      
      It's the place where add_timer() checks the pending timer.  It's clear
      that this may happen after the immediate restart without sync in our
      cases.
      
      So, the workaround here is just to use mod_timer() instead of
      add_timer().  This looks like a band-aid fix, but it's a right move,
      as snd_timer_interrupt() takes care of the continuous rearm of timer.
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6d834a77
    • Yuki Shibuya's avatar
      KVM: x86: Inject pending interrupt even if pending nmi exist · 3252026a
      Yuki Shibuya authored
      commit 321c5658 upstream.
      
      Non maskable interrupts (NMI) are preferred to interrupts in current
      implementation. If a NMI is pending and NMI is blocked by the result
      of nmi_allowed(), pending interrupt is not injected and
      enable_irq_window() is not executed, even if interrupts injection is
      allowed.
      
      In old kernel (e.g. 2.6.32), schedule() is often called in NMI context.
      In this case, interrupts are needed to execute iret that intends end
      of NMI. The flag of blocking new NMI is not cleared until the guest
      execute the iret, and interrupts are blocked by pending NMI. Due to
      this, iret can't be invoked in the guest, and the guest is starved
      until block is cleared by some events (e.g. canceling injection).
      
      This patch injects pending interrupts, when it's allowed, even if NMI
      is blocked. And, If an interrupts is pending after executing
      inject_pending_event(), enable_irq_window() is executed regardless of
      NMI pending counter.
      Signed-off-by: default avatarYuki Shibuya <shibuya.yk@ncos.nec.co.jp>
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [bwh: Backported to 3.2:
       - vcpu_enter_guest() is simpler because inject_pending_event() can't fail
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3252026a
    • Martin K. Petersen's avatar
      sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes · e7a5fd78
      Martin K. Petersen authored
      commit f08bb1e0 upstream.
      
      During revalidate we check whether device capacity has changed before we
      decide whether to output disk information or not.
      
      The check for old capacity failed to take into account that we scaled
      sdkp->capacity based on the reported logical block size. And therefore
      the capacity test would always fail for devices with sectors bigger than
      512 bytes and we would print several copies of the same discovery
      information.
      
      Avoid scaling sdkp->capacity and instead adjust the value on the fly
      when setting the block device capacity and generating fake C/H/S
      geometry.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Reported-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarHannes Reinicke <hare@suse.de>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      [bwh: Backported to 3.2:
       - logical_to_sectors() is a new function
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e7a5fd78
    • Oliver Neukum's avatar
      USB: digi_acceleport: do sanity checking for the number of ports · 38670829
      Oliver Neukum authored
      commit 5a07975a upstream.
      
      The driver can be crashed with devices that expose crafted descriptors
      with too few endpoints.
      
      See: http://seclists.org/bugtraq/2016/Mar/61Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      [johan: fix OOB endpoint check and add error messages ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      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>
      38670829
    • Oliver Neukum's avatar
      USB: cypress_m8: add endpoint sanity check · 2f974f8d
      Oliver Neukum authored
      commit c55aee1b upstream.
      
      An attack using missing endpoints exists.
      
      CVE-2016-3137
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2f974f8d
    • Oliver Neukum's avatar
      USB: mct_u232: add sanity checking in probe · b323f6de
      Oliver Neukum authored
      commit 4e9a0b05 upstream.
      
      An attack using the lack of sanity checking in probe is known. This
      patch checks for the existence of a second port.
      
      CVE-2016-3136
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      [johan: add error message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.2: put the check in mct_u232_startup(), which already
       has a 'serial' variable]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b323f6de
    • Vladis Dronov's avatar
      ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_audio_stream() call · 7836b6be
      Vladis Dronov authored
      commit 836b34a9 upstream.
      
      create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
      create_uaxx_quirk() functions allocate the audioformat object by themselves
      and free it upon error before returning. However, once the object is linked
      to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
      double-freed, eventually resulting in a memory corruption.
      
      This patch fixes these failures in the error paths by unlinking the audioformat
      object before freeing it.
      
      Based on a patch by Takashi Iwai <tiwai@suse.de>
      
      [Note for stable backports:
       this patch requires the commit 902eb7fd ('ALSA: usb-audio: Minor
       code cleanup in create_fixed_stream_quirk()')]
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7836b6be
    • Takashi Iwai's avatar
      ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk() · c26badfc
      Takashi Iwai authored
      commit 902eb7fd upstream.
      
      Just a minor code cleanup: unify the error paths.
      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>
      c26badfc
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer · 12ecd2fa
      Yoshihiro Shimoda authored
      commit 6490865c upstream.
      
      This patch adds a code to surely disable TX IRQ of the pipe before
      starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
      may happen in rare cases when DMAC is used.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      12ecd2fa
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() · 7eef6193
      Yoshihiro Shimoda authored
      commit 894f2fc4 upstream.
      
      When unexpected situation happened (e.g. tx/rx irq happened while
      DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
      pointer dereference like the followings:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 80000007 [#1] SMP ARM
      Modules linked in: usb_f_acm u_serial g_serial libcomposite
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
      Hardware name: Generic R8A7790 (Flattened Device Tree)
      task: c0729c00 ti: c0724000 task.ti: c0724000
      PC is at 0x0
      LR is at usbhsf_pkt_handler+0xac/0x118
      pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
      sp : c0725db8  ip : 00000000  fp : c0725df4
      r10: 00000001  r9 : 00000193  r8 : ef3ccab4
      r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
      r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4
      
      This patch adds a condition to avoid the dereference.
      
      Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7eef6193
    • Guenter Roeck's avatar
      hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated · ad955a93
      Guenter Roeck authored
      commit 3c2e2266 upstream.
      
      arm:pxa_defconfig can result in the following crash if the max1111 driver
      is not instantiated.
      
      Unhandled fault: page domain fault (0x01b) at 0x00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: : 1b [#1] PREEMPT ARM
      Modules linked in:
      CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680 #10
      Hardware name: SHARP Akita
      Workqueue: events sharpsl_charge_toggle
      task: c390a000 ti: c391e000 task.ti: c391e000
      PC is at max1111_read_channel+0x20/0x30
      LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c
      pc : [<c03aaab0>]    lr : [<c0024b50>]    psr: 20000013
      ...
      [<c03aaab0>] (max1111_read_channel) from [<c0024b50>]
      					(sharpsl_pm_pxa_read_max1111+0x2c/0x3c)
      [<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>]
      					(spitzpm_read_devdata+0x5c/0xc4)
      [<c00262e0>] (spitzpm_read_devdata) from [<c0024094>]
      					(sharpsl_check_battery_temp+0x78/0x110)
      [<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>]
      					(sharpsl_charge_toggle+0x48/0x110)
      [<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>]
      					(process_one_work+0x14c/0x48c)
      [<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4)
      [<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec)
      [<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24)
      
      This can occur because the SPI controller driver (SPI_PXA2XX) is built as
      module and thus not necessarily loaded. While building SPI_PXA2XX into the
      kernel would make the problem disappear, it appears prudent to ensure that
      the driver is instantiated before accessing its data structures.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ad955a93
    • Joseph Qi's avatar
      ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list · 2998e4fe
      Joseph Qi authored
      commit be12b299 upstream.
      
      When master handles convert request, it queues ast first and then
      returns status.  This may happen that the ast is sent before the request
      status because the above two messages are sent by two threads.  And
      right after the ast is sent, if master down, it may trigger BUG in
      dlm_move_lockres_to_recovery_list in the requested node because ast
      handler moves it to grant list without clear lock->convert_pending.  So
      remove BUG_ON statement and check if the ast is processed in
      dlmconvert_remote.
      Signed-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Reported-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Tariq Saeed <tariq.x.saeed@oracle.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.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>
      2998e4fe
    • Joseph Qi's avatar
      ocfs2/dlm: fix race between convert and recovery · 8d02fd0b
      Joseph Qi authored
      commit ac7cf246 upstream.
      
      There is a race window between dlmconvert_remote and
      dlm_move_lockres_to_recovery_list, which will cause a lock with
      OCFS2_LOCK_BUSY in grant list, thus system hangs.
      
      dlmconvert_remote
      {
              spin_lock(&res->spinlock);
              list_move_tail(&lock->list, &res->converting);
              lock->convert_pending = 1;
              spin_unlock(&res->spinlock);
      
              status = dlm_send_remote_convert_request();
              >>>>>> race window, master has queued ast and return DLM_NORMAL,
                     and then down before sending ast.
                     this node detects master down and calls
                     dlm_move_lockres_to_recovery_list, which will revert the
                     lock to grant list.
                     Then OCFS2_LOCK_BUSY won't be cleared as new master won't
                     send ast any more because it thinks already be authorized.
      
              spin_lock(&res->spinlock);
              lock->convert_pending = 0;
              if (status != DLM_NORMAL)
                      dlm_revert_pending_convert(res, lock);
              spin_unlock(&res->spinlock);
      }
      
      In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set
      (res is still in recovering) or res master changed (new master has
      finished recovery), reset the status to DLM_RECOVERING, then it will
      retry convert.
      Signed-off-by: default avatarJoseph Qi <joseph.qi@huawei.com>
      Reported-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Reviewed-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Tariq Saeed <tariq.x.saeed@oracle.com>
      Cc: Junxiao Bi <junxiao.bi@oracle.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>
      8d02fd0b
    • Guenter Roeck's avatar
      MAINTAINERS: Update mailing list and web page for hwmon subsystem · f3a602c6
      Guenter Roeck authored
      commit 968ce1b1 upstream.
      
      The old web page for the hwmon subsystem is no longer operational,
      and the mailing list has become unreliable. Move both to kernel.org.
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      [bwh: Backported to 3.2: the set of hwmon drivers is different, so do a
       search-and-replace for the same addresses]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f3a602c6
    • 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