1. 29 Sep, 2016 40 commits
    • Al Viro's avatar
      s390: get_user() should zero on failure · 1cdd2edb
      Al Viro authored
      commit fd2d2b19 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1cdd2edb
    • Al Viro's avatar
      score: fix __get_user/get_user · 9931f8fe
      Al Viro authored
      commit c2f18fa4 upstream.
      
      * should zero on any failure
      * __get_user() should use __copy_from_user(), not copy_from_user()
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9931f8fe
    • Al Viro's avatar
      sh64: failing __get_user() should zero · b5687db2
      Al Viro authored
      commit c6852389 upstream.
      
      It could be done in exception-handling bits in __get_user_b() et.al.,
      but the surgery involved would take more knowledge of sh64 details
      than I have or _want_ to have.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b5687db2
    • Al Viro's avatar
      m32r: fix __get_user() · 92fe4f77
      Al Viro authored
      commit c90a3bc5 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      92fe4f77
    • Al Viro's avatar
      mn10300: failing __get_user() and get_user() should zero · 9309c7dd
      Al Viro authored
      commit 43403eab upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9309c7dd
    • Al Viro's avatar
      fix minor infoleak in get_user_ex() · d42924ab
      Al Viro authored
      commit 1c109fab upstream.
      
      get_user_ex(x, ptr) should zero x on failure.  It's not a lot of a leak
      (at most we are leaking uninitialized 64bit value off the kernel stack,
      and in a fairly constrained situation, at that), but the fix is trivial,
      so...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [ This sat in different branch from the uaccess fixes since mid-August ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d42924ab
    • Al Viro's avatar
      microblaze: fix copy_from_user() · 2338cc7a
      Al Viro authored
      commit d0cf3851 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2338cc7a
    • Al Viro's avatar
      avr32: fix copy_from_user() · 93f38d00
      Al Viro authored
      commit 8630c322 upstream.
      
      really ugly, but apparently avr32 compilers turns access_ok() into
      something so bad that they want it in assembler.  Left that way,
      zeroing added in inline wrapper.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      93f38d00
    • Al Viro's avatar
      microblaze: fix __get_user() · 2c3d3571
      Al Viro authored
      commit e98b9e37 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2c3d3571
    • Ard Biesheuvel's avatar
      crypto: cryptd - initialize child shash_desc on import · 8d6f6eb1
      Ard Biesheuvel authored
      commit 0bd22235 upstream.
      
      When calling .import() on a cryptd ahash_request, the structure members
      that describe the child transform in the shash_desc need to be initialized
      like they are when calling .init()
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8d6f6eb1
    • Will Deacon's avatar
      arm64: spinlocks: implement smp_mb__before_spinlock() as smp_mb() · e5eb7be2
      Will Deacon authored
      commit 872c63fb upstream.
      
      smp_mb__before_spinlock() is intended to upgrade a spin_lock() operation
      to a full barrier, such that prior stores are ordered with respect to
      loads and stores occuring inside the critical section.
      
      Unfortunately, the core code defines the barrier as smp_wmb(), which
      is insufficient to provide the required ordering guarantees when used in
      conjunction with our load-acquire-based spinlock implementation.
      
      This patch overrides the arm64 definition of smp_mb__before_spinlock()
      to map to a full smp_mb().
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Reported-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e5eb7be2
    • Sebastian Reichel's avatar
      ARM: OMAP3: hwmod data: Add sysc information for DSI · f23a0f22
      Sebastian Reichel authored
      commit b46211d6 upstream.
      
      Add missing sysconfig/sysstatus information
      to OMAP3 hwmod. The information has been
      checked against OMAP34xx and OMAP36xx TRM.
      
      Without this change DSI block is not reset
      during boot, which is required for working
      Nokia N950 display.
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f23a0f22
    • Alan Stern's avatar
      USB: change bInterval default to 10 ms · ece4b3b5
      Alan Stern authored
      commit 08c5cd37 upstream.
      
      Some full-speed mceusb infrared transceivers contain invalid endpoint
      descriptors for their interrupt endpoints, with bInterval set to 0.
      In the past they have worked out okay with the mceusb driver, because
      the driver sets the bInterval field in the descriptor to 1,
      overwriting whatever value may have been there before.  However, this
      approach was never sanctioned by the USB core, and in fact it does not
      work with xHCI controllers, because they use the bInterval value that
      was present when the configuration was installed.
      
      Currently usbcore uses 32 ms as the default interval if the value in
      the endpoint descriptor is invalid.  It turns out that these IR
      transceivers don't work properly unless the interval is set to 10 ms
      or below.  To work around this mceusb problem, this patch changes the
      endpoint-descriptor parsing routine, making the default interval value
      be 10 ms rather than 32 ms.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarWade Berrier <wberrier@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ece4b3b5
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: fix clearing the {BRDY,BEMP}STS condition · 902d1e9e
      Yoshihiro Shimoda authored
      commit 519d8bd4 upstream.
      
      The previous driver is possible to stop the transfer wrongly.
      For example:
       1) An interrupt happens, but not BRDY interruption.
       2) Read INTSTS0. And than state->intsts0 is not set to BRDY.
       3) BRDY is set to 1 here.
       4) Read BRDYSTS.
       5) Clear the BRDYSTS. And then. the BRDY is cleared wrongly.
      
      Remarks:
       - The INTSTS0.BRDY is read only.
        - If any bits of BRDYSTS are set to 1, the BRDY is set to 1.
        - If BRDYSTS is 0, the BRDY is set to 0.
      
      So, this patch adds condition to avoid such situation. (And about
      NRDYSTS, this is not used for now. But, avoiding any side effects,
      this patch doesn't touch it.)
      
      Fixes: d5c6a1e0 ("usb: renesas_usbhs: fixup interrupt status clear method")
      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 avatarJiri Slaby <jslaby@suse.cz>
      902d1e9e
    • Daniele Palmas's avatar
      USB: serial: simple: add support for another Infineon flashloader · 399c48c6
      Daniele Palmas authored
      commit f190fd92 upstream.
      
      This patch adds support for Infineon flashloader 0x8087/0x0801.
      
      The flashloader is used in Telit LE940B modem family with Telit
      flashing application.
      Signed-off-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      399c48c6
    • Linus Walleij's avatar
      iio: accel: kxsd9: Fix scaling bug · 2f8c95d9
      Linus Walleij authored
      commit 307fe9dd upstream.
      
      All the scaling of the KXSD9 involves multiplication with a
      fraction number < 1.
      
      However the scaling value returned from IIO_INFO_SCALE was
      unpredictable as only the micros of the value was assigned, and
      not the integer part, resulting in scaling like this:
      
      $cat in_accel_scale
      -1057462640.011978
      
      Fix this by assigning zero to the integer part.
      Tested-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2f8c95d9
    • Linus Walleij's avatar
      iio: accel: kxsd9: Fix raw read return · 523e1dd7
      Linus Walleij authored
      commit 7ac61a06 upstream.
      
      Any readings from the raw interface of the KXSD9 driver will
      return an empty string, because it does not return
      IIO_VAL_INT but rather some random value from the accelerometer
      to the caller.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      523e1dd7
    • Suzuki K Poulose's avatar
      kvm-arm: Unmap shadow pagetables properly · da1fef74
      Suzuki K Poulose authored
      commit 293f2936 upstream.
      
      On arm/arm64, we depend on the kvm_unmap_hva* callbacks (via
      mmu_notifiers::invalidate_*) to unmap the stage2 pagetables when
      the userspace buffer gets unmapped. However, when the Hypervisor
      process exits without explicit unmap of the guest buffers, the only
      notifier we get is kvm_arch_flush_shadow_all() (via mmu_notifier::release
      ) which does nothing on arm. Later this causes us to access pages that
      were already released [via exit_mmap() -> unmap_vmas()] when we actually
      get to unmap the stage2 pagetable [via kvm_arch_destroy_vm() ->
      kvm_free_stage2_pgd()]. This triggers crashes with CONFIG_DEBUG_PAGEALLOC,
      which unmaps any free'd pages from the linear map.
      
       [  757.644120] Unable to handle kernel paging request at virtual address
        ffff800661e00000
       [  757.652046] pgd = ffff20000b1a2000
       [  757.655471] [ffff800661e00000] *pgd=00000047fffe3003, *pud=00000047fcd8c003,
        *pmd=00000047fcc7c003, *pte=00e8004661e00712
       [  757.666492] Internal error: Oops: 96000147 [#3] PREEMPT SMP
       [  757.672041] Modules linked in:
       [  757.675100] CPU: 7 PID: 3630 Comm: qemu-system-aar Tainted: G      D
       4.8.0-rc1 #3
       [  757.683240] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board,
        BIOS 3.06.15 Aug 19 2016
       [  757.692938] task: ffff80069cdd3580 task.stack: ffff8006adb7c000
       [  757.698840] PC is at __flush_dcache_area+0x1c/0x40
       [  757.703613] LR is at kvm_flush_dcache_pmd+0x60/0x70
       [  757.708469] pc : [<ffff20000809dbdc>] lr : [<ffff2000080b4a70>] pstate: 20000145
       ...
       [  758.357249] [<ffff20000809dbdc>] __flush_dcache_area+0x1c/0x40
       [  758.363059] [<ffff2000080b6748>] unmap_stage2_range+0x458/0x5f0
       [  758.368954] [<ffff2000080b708c>] kvm_free_stage2_pgd+0x34/0x60
       [  758.374761] [<ffff2000080b2280>] kvm_arch_destroy_vm+0x20/0x68
       [  758.380570] [<ffff2000080aa330>] kvm_put_kvm+0x210/0x358
       [  758.385860] [<ffff2000080aa524>] kvm_vm_release+0x2c/0x40
       [  758.391239] [<ffff2000082ad234>] __fput+0x114/0x2e8
       [  758.396096] [<ffff2000082ad46c>] ____fput+0xc/0x18
       [  758.400869] [<ffff200008104658>] task_work_run+0x108/0x138
       [  758.406332] [<ffff2000080dc8ec>] do_exit+0x48c/0x10e8
       [  758.411363] [<ffff2000080dd5fc>] do_group_exit+0x6c/0x130
       [  758.416739] [<ffff2000080ed924>] get_signal+0x284/0xa18
       [  758.421943] [<ffff20000808a098>] do_signal+0x158/0x860
       [  758.427060] [<ffff20000808aad4>] do_notify_resume+0x6c/0x88
       [  758.432608] [<ffff200008083624>] work_pending+0x10/0x14
       [  758.437812] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)
      
      This patch fixes the issue by moving the kvm_free_stage2_pgd() to
      kvm_arch_flush_shadow_all().
      Tested-by: default avatarItaru Kitayama <itaru.kitayama@riken.jp>
      Reported-by: default avatarItaru Kitayama <itaru.kitayama@riken.jp>
      Reported-by: default avatarJames Morse <james.morse@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      da1fef74
    • Steven Rostedt's avatar
      x86/paravirt: Do not trace _paravirt_ident_*() functions · 0e0aebc5
      Steven Rostedt authored
      commit 15301a57 upstream.
      
      Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up
      after enabling function tracer. I asked him to bisect the functions within
      available_filter_functions, which he did and it came down to three:
      
        _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64()
      
      It was found that this is only an issue when noreplace-paravirt is added
      to the kernel command line.
      
      This means that those functions are most likely called within critical
      sections of the funtion tracer, and must not be traced.
      
      In newer kenels _paravirt_nop() is defined within gcc asm(), and is no
      longer an issue.  But both _paravirt_ident_{32,64}() causes the
      following splat when they are traced:
      
       mm/pgtable-generic.c:33: bad pmd ffff8800d2435150(0000000001d00054)
       mm/pgtable-generic.c:33: bad pmd ffff8800d3624190(0000000001d00070)
       mm/pgtable-generic.c:33: bad pmd ffff8800d36a5110(0000000001d00054)
       mm/pgtable-generic.c:33: bad pmd ffff880118eb1450(0000000001d00054)
       NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:469]
       Modules linked in: e1000e
       CPU: 2 PID: 469 Comm: systemd-journal Not tainted 4.6.0-rc4-test+ #513
       Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
       task: ffff880118f740c0 ti: ffff8800d4aec000 task.ti: ffff8800d4aec000
       RIP: 0010:[<ffffffff81134148>]  [<ffffffff81134148>] queued_spin_lock_slowpath+0x118/0x1a0
       RSP: 0018:ffff8800d4aefb90  EFLAGS: 00000246
       RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011eb16d40
       RDX: ffffffff82485760 RSI: 000000001f288820 RDI: ffffea0000008030
       RBP: ffff8800d4aefb90 R08: 00000000000c0000 R09: 0000000000000000
       R10: ffffffff821c8e0e R11: 0000000000000000 R12: ffff880000200fb8
       R13: 00007f7a4e3f7000 R14: ffffea000303f600 R15: ffff8800d4b562e0
       FS:  00007f7a4e3d7840(0000) GS:ffff88011eb00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f7a4e3f7000 CR3: 00000000d3e71000 CR4: 00000000001406e0
       Call Trace:
         _raw_spin_lock+0x27/0x30
         handle_pte_fault+0x13db/0x16b0
         handle_mm_fault+0x312/0x670
         __do_page_fault+0x1b1/0x4e0
         do_page_fault+0x22/0x30
         page_fault+0x28/0x30
         __vfs_read+0x28/0xe0
         vfs_read+0x86/0x130
         SyS_read+0x46/0xa0
         entry_SYSCALL_64_fastpath+0x1e/0xa8
       Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14 c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7 4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b
      Reported-by: default avatarŁukasz Daniluk <lukasz.daniluk@intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      0e0aebc5
    • Mike Snitzer's avatar
      dm flakey: fix reads to be issued if drop_writes configured · bc45be85
      Mike Snitzer authored
      commit 299f6230 upstream.
      
      v4.8-rc3 commit 99f3c90d ("dm flakey: error READ bios during the
      down_interval") overlooked the 'drop_writes' feature, which is meant to
      allow reads to be issued rather than errored, during the down_interval.
      
      Fixes: 99f3c90d ("dm flakey: error READ bios during the down_interval")
      Reported-by: default avatarQu Wenruo <quwenruo@cn.fujitsu.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      bc45be85
    • Trond Myklebust's avatar
      NFSv4.x: Fix a refcount leak in nfs_callback_up_net · 55377ee2
      Trond Myklebust authored
      commit 98b0f80c upstream.
      
      On error, the callers expect us to return without bumping
      nn->cb_users[].
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      55377ee2
    • Paul Mackerras's avatar
      powerpc/mm: Don't alias user region to other regions below PAGE_OFFSET · 78d6a2c9
      Paul Mackerras authored
      commit f077aaf0 upstream.
      
      In commit c60ac569 ("powerpc: Update kernel VSID range", 2013-03-13)
      we lost a check on the region number (the top four bits of the effective
      address) for addresses below PAGE_OFFSET.  That commit replaced a check
      that the top 18 bits were all zero with a check that bits 46 - 59 were
      zero (performed for all addresses, not just user addresses).
      
      This means that userspace can access an address like 0x1000_0xxx_xxxx_xxxx
      and we will insert a valid SLB entry for it.  The VSID used will be the
      same as if the top 4 bits were 0, but the page size will be some random
      value obtained by indexing beyond the end of the mm_ctx_high_slices_psize
      array in the paca.  If that page size is the same as would be used for
      region 0, then userspace just has an alias of the region 0 space.  If the
      page size is different, then no HPTE will be found for the access, and
      the process will get a SIGSEGV (since hash_page_mm() will refuse to create
      a HPTE for the bogus address).
      
      The access beyond the end of the mm_ctx_high_slices_psize can be at most
      5.5MB past the array, and so will be in RAM somewhere.  Since the access
      is a load performed in real mode, it won't fault or crash the kernel.
      At most this bug could perhaps leak a little bit of information about
      blocks of 32 bytes of memory located at offsets of i * 512kB past the
      paca->mm_ctx_high_slices_psize array, for 1 <= i <= 11.
      
      Fixes: c60ac569 ("powerpc: Update kernel VSID range")
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      78d6a2c9
    • Chen-Yu Tsai's avatar
      clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function · 68151411
      Chen-Yu Tsai authored
      commit b53e7d00 upstream.
      
      The bootloader (U-boot) sometimes uses this timer for various delays.
      It uses it as a ongoing counter, and does comparisons on the current
      counter value. The timer counter is never stopped.
      
      In some cases when the user interacts with the bootloader, or lets
      it idle for some time before loading Linux, the timer may expire,
      and an interrupt will be pending. This results in an unexpected
      interrupt when the timer interrupt is enabled by the kernel, at
      which point the event_handler isn't set yet. This results in a NULL
      pointer dereference exception, panic, and no way to reboot.
      
      Clear any pending interrupts after we stop the timer in the probe
      function to avoid this.
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      68151411
    • Jiri Kosina's avatar
      x86/mm/pat, /dev/mem: Remove superfluous error message · 25da72e9
      Jiri Kosina authored
      commit 39380b80 upstream.
      
      Currently it's possible for broken (or malicious) userspace to flood a
      kernel log indefinitely with messages a-la
      
      	Program dmidecode tried to access /dev/mem between f0000->100000
      
      because range_is_allowed() is case of CONFIG_STRICT_DEVMEM being turned on
      dumps this information each and every time devmem_is_allowed() fails.
      
      Reportedly userspace that is able to trigger contignuous flow of these
      messages exists.
      
      It would be possible to rate limit this message, but that'd have a
      questionable value; the administrator wouldn't get information about all
      the failing accessess, so then the information would be both superfluous
      and incomplete at the same time :)
      
      Returning EPERM (which is what is actually happening) is enough indication
      for userspace what has happened; no need to log this particular error as
      some sort of special condition.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1607081137020.24757@cbobk.fhfr.pmSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      25da72e9
    • Michal Kubecek's avatar
      ipvs: count pre-established TCP states as active · b9fe5ee1
      Michal Kubecek authored
      commit be2cef49 upstream.
      
      Some users observed that "least connection" distribution algorithm doesn't
      handle well bursts of TCP connections from reconnecting clients after
      a node or network failure.
      
      This is because the algorithm counts active connection as worth 256
      inactive ones where for TCP, "active" only means TCP connections in
      ESTABLISHED state. In case of a connection burst, new connections are
      handled before previous ones have finished the three way handshaking so
      that all are still counted as "inactive", i.e. cheap ones. The become
      "active" quickly but at that time, all of them are already assigned to one
      real server (or few), resulting in highly unbalanced distribution.
      
      Address this by counting the "pre-established" states as "active".
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b9fe5ee1
    • Michal Kubecek's avatar
      net: disable fragment reassembly if high_thresh is set to zero · af29d5b5
      Michal Kubecek authored
      commit 30759219 upstream.
      
      Before commit 6d7b857d ("net: use lib/percpu_counter API for
      fragmentation mem accounting"), setting high threshold to 0 prevented
      fragment reassembly as first fragment would be always evicted before
      second could be added to the queue. While inefficient, some users
      apparently relied on it.
      
      Since the commit mentioned above, a percpu counter is used for
      reassembly memory accounting and high batch size avoids taking slow path
      in most common scenarios. As a result, a whole full sized packet can be
      reassembled without the percpu counter's main counter changing its
      value so that even with high_thresh set to 0, fragmented packets can be
      still reassembled and processed.
      
      Add explicit checks preventing reassembly if high threshold is zero.
      
      [mk] backport to 3.12
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      af29d5b5
    • Emrah Demir's avatar
      mISDN: Fixing missing validation in base_sock_bind() · dea85278
      Emrah Demir authored
      commit b8216468 upstream.
      
      Add validation code into mISDN/socket.c
      Signed-off-by: default avatarEmrah Demir <ed@abdsec.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Oliver Neukum <oliver@neukum.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      dea85278
    • Maciej S. Szmigiero's avatar
      mISDN: Support DR6 indication in mISDNipac driver · a770479a
      Maciej S. Szmigiero authored
      commit 1e1589ad upstream.
      
      According to figure 39 in PEB3086 data sheet, version 1.4 this indication
      replaces DR when layer 1 transition source state is F6.
      
      This fixes mISDN layer 1 getting stuck in F6 state in TE mode on
      Dialogic Diva 2.02 card (and possibly others) when NT deactivates it.
      Signed-off-by: default avatarMaciej S. Szmigiero <mail@maciej.szmigiero.name>
      Acked-by: default avatarKarsten Keil <keil@b1-systems.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Oliver Neukum <oliver@neukum.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a770479a
    • Jean-Gabriel Gill-Couture's avatar
      HID: add usb device id for Apple Magic Keyboard · 9df73f85
      Jean-Gabriel Gill-Couture authored
      commit b5d94275 upstream.
      
      USB device
      	Vendor 05ac (Apple)
      	Device 0267 (Magic Keyboard)
      
      This keyboard supports both Bluetooth and USB connections, this patch
      only covers USB.
      
      Thanks to Maxime Poulin <maxpoulin64@gmail.com>
      Signed-off-by: default avatarJean-Gabriel Gill-Couture <jeangab@jeangab.fr.nf>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Cc: Oliver Neukum <oliver@neukum.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9df73f85
    • Dmitry Torokhov's avatar
      Input: ili210x - fix permissions on "calibrate" attribute · 5680d5b7
      Dmitry Torokhov authored
      commit b27c0d0c upstream.
      
      "calibrate" attribute does not provide "show" methods and thus we should
      not mark it as readable.
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Oliver Neukum <oliver@neukum.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      5680d5b7
    • Krzysztof Kozlowski's avatar
      hwrng: exynos - Disable runtime PM on probe failure · 7d3ca069
      Krzysztof Kozlowski authored
      commit 48a61e1e upstream.
      
      Add proper error path (for disabling runtime PM) when registering of
      hwrng fails.
      
      Fixes: b329669e ("hwrng: exynos - Add support for Exynos random number generator")
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      7d3ca069
    • Sai Gurrappadi's avatar
      cpufreq: Fix GOV_LIMITS handling for the userspace governor · 5fd55fb3
      Sai Gurrappadi authored
      commit e43e94c1 upstream.
      
      Currently, the userspace governor only updates frequency on GOV_LIMITS
      if policy->cur falls outside policy->{min/max}. However, it is also
      necessary to update current frequency on GOV_LIMITS to match the user
      requested value if it can be achieved within the new policy->{max/min}.
      
      This was previously the behaviour in the governor until commit d1922f02
      ("cpufreq: Simplify userspace governor") which incorrectly assumed that
      policy->cur == user requested frequency via scaling_setspeed. This won't
      be true if the user requested frequency falls outside policy->{min/max}.
      Ex: a temporary thermal cap throttled the user requested frequency.
      
      Fix this by storing the user requested frequency in a seperate variable.
      The governor will then try to achieve this request on every GOV_LIMITS
      change.
      
      Fixes: d1922f02 (cpufreq: Simplify userspace governor)
      Signed-off-by: default avatarSai Gurrappadi <sgurrappadi@nvidia.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      5fd55fb3
    • Tyrel Datwyler's avatar
      scsi: fix upper bounds check of sense key in scsi_sense_key_string() · b0c04f74
      Tyrel Datwyler authored
      commit a87eeb90 upstream.
      
      Commit 655ee63c ("scsi constants: command, sense key + additional
      sense string") added a "Completed" sense string with key 0xF to
      snstext[], but failed to updated the upper bounds check of the sense key
      in scsi_sense_key_string().
      
      Fixes: 655ee63c ("[SCSI] scsi constants: command, sense key + additional sense strings")
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b0c04f74
    • Vegard Nossum's avatar
      ALSA: timer: fix NULL pointer dereference on memory allocation failure · bca643b2
      Vegard Nossum authored
      commit 8ddc0563 upstream.
      
      I hit this with syzkaller:
      
          kasan: CONFIG_KASAN_INLINE enabled
          kasan: GPF could be caused by NULL-ptr deref or user memory access
          general protection fault: 0000 [#1] PREEMPT SMP KASAN
          CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
          task: ffff88011278d600 task.stack: ffff8801120c0000
          RIP: 0010:[<ffffffff82c8ba07>]  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
          RSP: 0018:ffff8801120c7a60  EFLAGS: 00010006
          RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
          RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
          RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
          R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
          R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
          FS:  00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
          Stack:
           ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
           ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
           ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
          Call Trace:
           [<ffffffff82c81ab1>] snd_timer_start1+0x331/0x670
           [<ffffffff82c85bfd>] snd_timer_start+0x5d/0xa0
           [<ffffffff82c8795e>] snd_timer_user_ioctl+0x88e/0x2830
           [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
           [<ffffffff8132762f>] ? put_prev_entity+0x108f/0x21a0
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
           [<ffffffff813510af>] ? cpuacct_account_field+0x12f/0x1a0
           [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
           [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
           [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
           [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
           [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
           [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
           [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
           [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
          Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
          RIP  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
           RSP <ffff8801120c7a60>
          ---[ end trace 5955b08db7f2b029 ]---
      
      This can happen if snd_hrtimer_open() fails to allocate memory and
      returns an error, which is currently not checked by snd_timer_open():
      
          ioctl(SNDRV_TIMER_IOCTL_SELECT)
           - snd_timer_user_tselect()
      	- snd_timer_close()
      	   - snd_hrtimer_close()
      	      - (struct snd_timer *) t->private_data = NULL
              - snd_timer_open()
                 - snd_hrtimer_open()
                    - kzalloc() fails; t->private_data is still NULL
      
          ioctl(SNDRV_TIMER_IOCTL_START)
           - snd_timer_user_start()
      	- snd_timer_start()
      	   - snd_timer_start1()
      	      - snd_hrtimer_start()
      		- t->private_data == NULL // boom
      
      [js] no put_device in 3.12 yet
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      bca643b2
    • Vegard Nossum's avatar
      ALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE · f3b1afe3
      Vegard Nossum authored
      commit 6b760bb2 upstream.
      
      I got this:
      
          divide error: 0000 [#1] PREEMPT SMP KASAN
          CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
          task: ffff8801120a9580 task.stack: ffff8801120b0000
          RIP: 0010:[<ffffffff82c8bd9a>]  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
          RSP: 0018:ffff88011aa87da8  EFLAGS: 00010006
          RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000
          RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001
          RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048
          R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00
          R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000
          FS:  00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0
          Stack:
           0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
           ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
           00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
          Call Trace:
           <IRQ>
           [<ffffffff813abce7>] __hrtimer_run_queues+0x347/0xa00
           [<ffffffff82c8bbc0>] ? snd_hrtimer_close+0x130/0x130
           [<ffffffff813ab9a0>] ? retrigger_next_event+0x1b0/0x1b0
           [<ffffffff813ae1a6>] ? hrtimer_interrupt+0x136/0x4b0
           [<ffffffff813ae220>] hrtimer_interrupt+0x1b0/0x4b0
           [<ffffffff8120f91e>] local_apic_timer_interrupt+0x6e/0xf0
           [<ffffffff81227ad3>] ? kvm_guest_apic_eoi_write+0x13/0xc0
           [<ffffffff83c35086>] smp_apic_timer_interrupt+0x76/0xa0
           [<ffffffff83c3416c>] apic_timer_interrupt+0x8c/0xa0
           <EOI>
           [<ffffffff83c3239c>] ? _raw_spin_unlock_irqrestore+0x2c/0x60
           [<ffffffff82c8185d>] snd_timer_start1+0xdd/0x670
           [<ffffffff82c87015>] snd_timer_continue+0x45/0x80
           [<ffffffff82c88100>] snd_timer_user_ioctl+0x1030/0x2830
           [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
           [<ffffffff815aa4f8>] ? handle_mm_fault+0xbc8/0x27f0
           [<ffffffff815a9930>] ? __pmd_alloc+0x370/0x370
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
           [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
           [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
           [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
           [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
           [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
           [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
           [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
           [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
          Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 <48> f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
          RIP  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
           RSP <ffff88011aa87da8>
          ---[ end trace 6aa380f756a21074 ]---
      
      The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
      completely new/unused timer -- it will have ->sticks == 0, which causes a
      divide by 0 in snd_hrtimer_callback().
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f3b1afe3
    • Vegard Nossum's avatar
      ALSA: timer: fix NULL pointer dereference in read()/ioctl() race · d244fbcc
      Vegard Nossum authored
      commit 11749e08 upstream.
      
      I got this with syzkaller:
      
          ==================================================================
          BUG: KASAN: null-ptr-deref on address 0000000000000020
          Read of size 32 by task syz-executor/22519
          CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
          014
           0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
           ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
           ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
          Call Trace:
           [<ffffffff81f9f141>] dump_stack+0x83/0xb2
           [<ffffffff8161fe3f>] kasan_report_error+0x41f/0x4c0
           [<ffffffff8161ff74>] kasan_report+0x34/0x40
           [<ffffffff82c84b54>] ? snd_timer_user_read+0x554/0x790
           [<ffffffff8161e79e>] check_memory_region+0x13e/0x1a0
           [<ffffffff8161e9c1>] kasan_check_read+0x11/0x20
           [<ffffffff82c84b54>] snd_timer_user_read+0x554/0x790
           [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
           [<ffffffff817d0831>] ? proc_fault_inject_write+0x1c1/0x250
           [<ffffffff817d0670>] ? next_tgid+0x2a0/0x2a0
           [<ffffffff8127c278>] ? do_group_exit+0x108/0x330
           [<ffffffff8174653a>] ? fsnotify+0x72a/0xca0
           [<ffffffff81674dfe>] __vfs_read+0x10e/0x550
           [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
           [<ffffffff81674cf0>] ? do_sendfile+0xc50/0xc50
           [<ffffffff81745e10>] ? __fsnotify_update_child_dentry_flags+0x60/0x60
           [<ffffffff8143fec6>] ? kcov_ioctl+0x56/0x190
           [<ffffffff81e5ada2>] ? common_file_perm+0x2e2/0x380
           [<ffffffff81746b0e>] ? __fsnotify_parent+0x5e/0x2b0
           [<ffffffff81d93536>] ? security_file_permission+0x86/0x1e0
           [<ffffffff816728f5>] ? rw_verify_area+0xe5/0x2b0
           [<ffffffff81675355>] vfs_read+0x115/0x330
           [<ffffffff81676371>] SyS_read+0xd1/0x1a0
           [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
           [<ffffffff82001c2c>] ? __this_cpu_preempt_check+0x1c/0x20
           [<ffffffff8150455a>] ? __context_tracking_exit.part.4+0x3a/0x1e0
           [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff810052fc>] ? syscall_return_slowpath+0x16c/0x1d0
           [<ffffffff83c3276a>] entry_SYSCALL64_slow_path+0x25/0x25
          ==================================================================
      
      There are a couple of problems that I can see:
      
       - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
         tu->queue/tu->tqueue to NULL on memory allocation failure, so read()
         would get a NULL pointer dereference like the above splat
      
       - the same ioctl() can free tu->queue/to->tqueue which means read()
         could potentially see (and dereference) the freed pointer
      
      We can fix both by taking the ioctl_lock mutex when dereferencing
      ->queue/->tqueue, since that's always held over all the ioctl() code.
      
      Just looking at the code I find it likely that there are more problems
      here such as tu->qhead pointing outside the buffer if the size is
      changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.
      
      [js] unlock in fail paths
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d244fbcc
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix possible deadlock with virmidi registration · 72fe6c43
      Takashi Iwai authored
      commit 816f318b upstream.
      
      When a seq-virmidi driver is initialized, it registers a rawmidi
      instance with its callback to create an associated seq kernel client.
      Currently it's done throughly in rawmidi's register_mutex context.
      Recently it was found that this may lead to a deadlock another rawmidi
      device that is being attached with the sequencer is accessed, as both
      open with the same register_mutex.  This was actually triggered by
      syzkaller, as Dmitry Vyukov reported:
      
      ======================================================
       [ INFO: possible circular locking dependency detected ]
       4.8.0-rc1+ #11 Not tainted
       -------------------------------------------------------
       syz-executor/7154 is trying to acquire lock:
        (register_mutex#5){+.+.+.}, at: [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
      
       but task is already holding lock:
        (&grp->list_mutex){++++.+}, at: [<ffffffff850138bb>] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&grp->list_mutex){++++.+}:
          [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
          [<ffffffff863f6199>] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
          [<     inline     >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
          [<ffffffff85005c5e>] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
          [<ffffffff85006e96>] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
          [<ffffffff85012c52>] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
          [<ffffffff84fff70a>] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
          [<     inline     >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
          [<ffffffff8502d29f>] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
          [<ffffffff84fd208c>] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
          [<ffffffff84f816d3>] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
          [<     inline     >] __snd_device_register sound/core/device.c:162
          [<ffffffff84f8235d>] snd_device_register_all+0xad/0x110 sound/core/device.c:212
          [<ffffffff84f7546f>] snd_card_register+0xef/0x6c0 sound/core/init.c:749
          [<ffffffff85040b7f>] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
          [<ffffffff833ebf7b>] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
          ......
      
       -> #0 (register_mutex#5){+.+.+.}:
          [<     inline     >] check_prev_add kernel/locking/lockdep.c:1829
          [<     inline     >] check_prevs_add kernel/locking/lockdep.c:1939
          [<     inline     >] validate_chain kernel/locking/lockdep.c:2266
          [<ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
          [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
          [<     inline     >] __mutex_lock_common kernel/locking/mutex.c:521
          [<ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
          [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
          [<ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
          [<     inline     >] subscribe_port sound/core/seq/seq_ports.c:427
          [<ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
          [<ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
          [<ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
          [<ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
          [<ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
          [<ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
          [<ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
          [<ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
          [<ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
          [<ffffffff84f7040f>] soundcore_open+0x30f/0x640 sound/sound_core.c:639
          ......
      
       other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&grp->list_mutex);
                                      lock(register_mutex#5);
                                      lock(&grp->list_mutex);
         lock(register_mutex#5);
      
       *** DEADLOCK ***
      ======================================================
      
      The fix is to simply move the registration parts in
      snd_rawmidi_dev_register() to the outside of the register_mutex lock.
      The lock is needed only to manage the linked list, and it's not
      necessarily to cover the whole initialization process.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      72fe6c43
    • Wanpeng Li's avatar
      x86/apic: Do not init irq remapping if ioapic is disabled · 434ada5f
      Wanpeng Li authored
      commit 2e63ad4b upstream.
      
      native_smp_prepare_cpus
        -> default_setup_apic_routing
          -> enable_IR_x2apic
            -> irq_remapping_prepare
              -> intel_prepare_irq_remapping
                -> intel_setup_irq_remapping
      
      So IR table is setup even if "noapic" boot parameter is added. As a result we
      crash later when the interrupt affinity is set due to a half initialized
      remapping infrastructure.
      
      Prevent remap initialization when IOAPIC is disabled.
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Joerg Roedel <joro@8bytes.org>
      Link: http://lkml.kernel.org/r/1471954039-3942-1-git-send-email-wanpeng.li@hotmail.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      434ada5f
    • Vincent Stehlé's avatar
      ubifs: Fix assertion in layout_in_gaps() · 67e71ed6
      Vincent Stehlé authored
      commit c0082e98 upstream.
      
      An assertion in layout_in_gaps() verifies that the gap_lebs pointer is
      below the maximum bound. When computing this maximum bound the idx_lebs
      count is multiplied by sizeof(int), while C pointers arithmetic does take
      into account the size of the pointed elements implicitly already. Remove
      the multiplication to fix the assertion.
      
      Fixes: 1e51764a ("UBIFS: add new flash file system")
      Signed-off-by: default avatarVincent Stehlé <vincent.stehle@intel.com>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      67e71ed6
    • John Stultz's avatar
      timekeeping: Cap array access in timekeeping_debug · 4a47090a
      John Stultz authored
      commit a4f8f666 upstream.
      
      It was reported that hibernation could fail on the 2nd attempt, where the
      system hangs at hibernate() -> syscore_resume() -> i8237A_resume() ->
      claim_dma_lock(), because the lock has already been taken.
      
      However there is actually no other process would like to grab this lock on
      that problematic platform.
      
      Further investigation showed that the problem is triggered by setting
      /sys/power/pm_trace to 1 before the 1st hibernation.
      
      Since once pm_trace is enabled, the rtc becomes unmeaningful after suspend,
      and meanwhile some BIOSes would like to adjust the 'invalid' RTC (e.g, smaller
      than 1970) to the release date of that motherboard during POST stage, thus
      after resumed, it may seem that the system had a significant long sleep time
      which is a completely meaningless value.
      
      Then in timekeeping_resume -> tk_debug_account_sleep_time, if the bit31 of the
      sleep time happened to be set to 1, fls() returns 32 and we add 1 to
      sleep_time_bin[32], which causes an out of bounds array access and therefor
      memory being overwritten.
      
      As depicted by System.map:
      0xffffffff81c9d080 b sleep_time_bin
      0xffffffff81c9d100 B dma_spin_lock
      the dma_spin_lock.val is set to 1, which caused this problem.
      
      This patch adds a sanity check in tk_debug_account_sleep_time()
      to ensure we don't index past the sleep_time_bin array.
      
      [jstultz: Problem diagnosed and original patch by Chen Yu, I've solved the
       issue slightly differently, but borrowed his excelent explanation of the
       issue here.]
      
      Fixes: 5c83545f "power: Add option to log time spent in suspend"
      Reported-by: default avatarJanek Kozicki <cosurgi@gmail.com>
      Reported-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Cc: linux-pm@vger.kernel.org
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Xunlei Pang <xpang@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Link: http://lkml.kernel.org/r/1471993702-29148-3-git-send-email-john.stultz@linaro.orgSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      4a47090a