1. 16 May, 2019 3 commits
    • Jiaxun Yang's avatar
      platform/x86: thinkpad_acpi: Disable Bluetooth for some machines · 1ca1dc64
      Jiaxun Yang authored
      commit f7db839f
      
       upstream.
      
      Some AMD based ThinkPads have a firmware bug that calling
      "GBDC" will cause Bluetooth on Intel wireless cards blocked.
      
      Probe these models by DMI match and disable Bluetooth subdriver
      if specified Intel wireless card exist.
      
      Cc: stable <stable@vger.kernel.org> # 4.14+
      Signed-off-by: default avatarJiaxun Yang <jiaxun.yang@flygoat.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ca1dc64
    • Gustavo A. R. Silva's avatar
      platform/x86: sony-laptop: Fix unintentional fall-through · 8be32597
      Gustavo A. R. Silva authored
      commit 1cbd7a64 upstream.
      
      It seems that the default case should return AE_CTRL_TERMINATE, instead
      of falling through to case ACPI_RESOURCE_TYPE_END_TAG and returning AE_OK;
      otherwise the line of code at the end of the function is unreachable and
      makes no sense:
      
      return AE_CTRL_TERMINATE;
      
      This fix is based on the following thread of discussion:
      
      https://lore.kernel.org/patchwork/patch/959782/
      
      Fixes: 33a04454
      
       ("sony-laptop: Add SNY6001 device handling (sonypi reimplementation)")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8be32597
    • Francesco Ruggeri's avatar
      netfilter: compat: initialize all fields in xt_init · 2ea2ee85
      Francesco Ruggeri authored
      commit 8d29d16d
      
       upstream
      
      If a non zero value happens to be in xt[NFPROTO_BRIDGE].cur at init
      time, the following panic can be caused by running
      
      % ebtables -t broute -F BROUTING
      
      from a 32-bit user level on a 64-bit kernel. This patch replaces
      kmalloc_array with kcalloc when allocating xt.
      
      [  474.680846] BUG: unable to handle kernel paging request at 0000000009600920
      [  474.687869] PGD 2037006067 P4D 2037006067 PUD 2038938067 PMD 0
      [  474.693838] Oops: 0000 [#1] SMP
      [  474.697055] CPU: 9 PID: 4662 Comm: ebtables Kdump: loaded Not tainted 4.19.17-11302235.AroraKernelnext.fc18.x86_64 #1
      [  474.707721] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.0 06/28/2013
      [  474.714313] RIP: 0010:xt_compat_calc_jump+0x2f/0x63 [x_tables]
      [  474.720201] Code: 40 0f b6 ff 55 31 c0 48 6b ff 70 48 03 3d dc 45 00 00 48 89 e5 8b 4f 6c 4c 8b 47 60 ff c9 39 c8 7f 2f 8d 14 08 d1 fa 48 63 fa <41> 39 34 f8 4c 8d 0c fd 00 00 00 00 73 05 8d 42 01 eb e1 76 05 8d
      [  474.739023] RSP: 0018:ffffc9000943fc58 EFLAGS: 00010207
      [  474.744296] RAX: 0000000000000000 RBX: ffffc90006465000 RCX: 0000000002580249
      [  474.751485] RDX: 00000000012c0124 RSI: fffffffff7be17e9 RDI: 00000000012c0124
      [  474.758670] RBP: ffffc9000943fc58 R08: 0000000000000000 R09: ffffffff8117cf8f
      [  474.765855] R10: ffffc90006477000 R11: 0000000000000000 R12: 0000000000000001
      [  474.773048] R13: 0000000000000000 R14: ffffc9000943fcb8 R15: ffffc9000943fcb8
      [  474.780234] FS:  0000000000000000(0000) GS:ffff88a03f840000(0063) knlGS:00000000f7ac7700
      [  474.788612] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
      [  474.794632] CR2: 0000000009600920 CR3: 0000002037422006 CR4: 00000000000606e0
      [  474.802052] Call Trace:
      [  474.804789]  compat_do_replace+0x1fb/0x2a3 [ebtables]
      [  474.810105]  compat_do_ebt_set_ctl+0x69/0xe6 [ebtables]
      [  474.815605]  ? try_module_get+0x37/0x42
      [  474.819716]  compat_nf_setsockopt+0x4f/0x6d
      [  474.824172]  compat_ip_setsockopt+0x7e/0x8c
      [  474.828641]  compat_raw_setsockopt+0x16/0x3a
      [  474.833220]  compat_sock_common_setsockopt+0x1d/0x24
      [  474.838458]  __compat_sys_setsockopt+0x17e/0x1b1
      [  474.843343]  ? __check_object_size+0x76/0x19a
      [  474.847960]  __ia32_compat_sys_socketcall+0x1cb/0x25b
      [  474.853276]  do_fast_syscall_32+0xaf/0xf6
      [  474.857548]  entry_SYSENTER_compat+0x6b/0x7a
      Signed-off-by: default avatarFrancesco Ruggeri <fruggeri@arista.com>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarZubin Mithra <zsm@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2ea2ee85
  2. 14 May, 2019 33 commits
  3. 10 May, 2019 4 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.118 · d929572d
      Greg Kroah-Hartman authored
      d929572d
    • Will Deacon's avatar
      arm64: futex: Bound number of LDXR/STXR loops in FUTEX_WAKE_OP · d5d05286
      Will Deacon authored
      commit 03110a5c upstream.
      
      Our futex implementation makes use of LDXR/STXR loops to perform atomic
      updates to user memory from atomic context. This can lead to latency
      problems if we end up spinning around the LL/SC sequence at the expense
      of doing something useful.
      
      Rework our futex atomic operations so that we return -EAGAIN if we fail
      to update the futex word after 128 attempts. The core futex code will
      reschedule if necessary and we'll try again later.
      
      Cc: <stable@kernel.org>
      Fixes: 6170a974
      
       ("arm64: Atomic operations")
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5d05286
    • Will Deacon's avatar
      locking/futex: Allow low-level atomic operations to return -EAGAIN · d2045151
      Will Deacon authored
      commit 6b4f4bc9
      
       upstream.
      
      Some futex() operations, including FUTEX_WAKE_OP, require the kernel to
      perform an atomic read-modify-write of the futex word via the userspace
      mapping. These operations are implemented by each architecture in
      arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic(), which
      are called in atomic context with the relevant hash bucket locks held.
      
      Although these routines may return -EFAULT in response to a page fault
      generated when accessing userspace, they are expected to succeed (i.e.
      return 0) in all other cases. This poses a problem for architectures
      that do not provide bounded forward progress guarantees or fairness of
      contended atomic operations and can lead to starvation in some cases.
      
      In these problematic scenarios, we must return back to the core futex
      code so that we can drop the hash bucket locks and reschedule if
      necessary, much like we do in the case of a page fault.
      
      Allow architectures to return -EAGAIN from their implementations of
      arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic(), which
      will cause the core futex code to reschedule if necessary and return
      back to the architecture code later on.
      
      Cc: <stable@kernel.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2045151
    • Ross Zwisler's avatar
      ASoC: Intel: avoid Oops if DMA setup fails · 34f9130a
      Ross Zwisler authored
      commit 0efa3334
      
       upstream.
      
      Currently in sst_dsp_new() if we get an error return from sst_dma_new()
      we just print an error message and then still complete the function
      successfully.  This means that we are trying to run without sst->dma
      properly set up, which will result in NULL pointer dereference when
      sst->dma is later used.  This was happening for me in
      sst_dsp_dma_get_channel():
      
              struct sst_dma *dma = dsp->dma;
      	...
              dma->ch = dma_request_channel(mask, dma_chan_filter, dsp);
      
      This resulted in:
      
         BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
         IP: sst_dsp_dma_get_channel+0x4f/0x125 [snd_soc_sst_firmware]
      
      Fix this by adding proper error handling for the case where we fail to
      set up DMA.
      
      This change only affects Haswell and Broadwell systems.  Baytrail
      systems explicilty opt-out of DMA via sst->pdata->resindex_dma_base
      being set to -1.
      Signed-off-by: default avatarRoss Zwisler <zwisler@google.com>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34f9130a