1. 20 Feb, 2019 40 commits
    • Eric W. Biederman's avatar
      signal: Restore the stop PTRACE_EVENT_EXIT · 492647b2
      Eric W. Biederman authored
      commit cf43a757fd49442bc38f76088b70c2299eed2c2f upstream.
      
      In the middle of do_exit() there is there is a call
      "ptrace_event(PTRACE_EVENT_EXIT, code);" That call places the process
      in TACKED_TRACED aka "(TASK_WAKEKILL | __TASK_TRACED)" and waits for
      for the debugger to release the task or SIGKILL to be delivered.
      
      Skipping past dequeue_signal when we know a fatal signal has already
      been delivered resulted in SIGKILL remaining pending and
      TIF_SIGPENDING remaining set.  This in turn caused the
      scheduler to not sleep in PTACE_EVENT_EXIT as it figured
      a fatal signal was pending.  This also caused ptrace_freeze_traced
      in ptrace_check_attach to fail because it left a per thread
      SIGKILL pending which is what fatal_signal_pending tests for.
      
      This difference in signal state caused strace to report
      strace: Exit of unknown pid NNNNN ignored
      
      Therefore update the signal handling state like dequeue_signal
      would when removing a per thread SIGKILL, by removing SIGKILL
      from the per thread signal mask and clearing TIF_SIGPENDING.
      Acked-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: 's avatarIvan Delalande <colona@arista.com>
      Cc: stable@vger.kernel.org
      Fixes: 35634ffa1751 ("signal: Always notice exiting tasks")
      Signed-off-by: 's avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      492647b2
    • Hedi Berriche's avatar
      x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls · 7212e37c
      Hedi Berriche authored
      commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.
      
      Calls into UV firmware must be protected against concurrency, expose the
      efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
      calls.
      Signed-off-by: 's avatarHedi Berriche <hedi.berriche@hpe.com>
      Signed-off-by: 's avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: 's avatarRuss Anderson <rja@hpe.com>
      Reviewed-by: 's avatarDimitri Sivanich <sivanich@hpe.com>
      Reviewed-by: 's avatarMike Travis <mike.travis@hpe.com>
      Cc: Andy Shevchenko <andy@infradead.org>
      Cc: Bhupesh Sharma <bhsharma@redhat.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-efi <linux-efi@vger.kernel.org>
      Cc: platform-driver-x86@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.9+
      Cc: Steve Wahl <steve.wahl@hpe.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7212e37c
    • Andreas Ziegler's avatar
      tracing/uprobes: Fix output for multiple string arguments · 137f4db1
      Andreas Ziegler authored
      commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.
      
      When printing multiple uprobe arguments as strings the output for the
      earlier arguments would also include all later string arguments.
      
      This is best explained in an example:
      
      Consider adding a uprobe to a function receiving two strings as
      parameters which is at offset 0xa0 in strlib.so and we want to print
      both parameters when the uprobe is hit (on x86_64):
      
      $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
          /sys/kernel/debug/tracing/uprobe_events
      
      When the function is called as func("foo", "bar") and we hit the probe,
      the trace file shows a line like the following:
      
        [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
      
      Note the extra "bar" printed as part of arg1. This behaviour stacks up
      for additional string arguments.
      
      The strings are stored in a dynamically growing part of the uprobe
      buffer by fetch_store_string() after copying them from userspace via
      strncpy_from_user(). The return value of strncpy_from_user() is then
      directly used as the required size for the string. However, this does
      not take the terminating null byte into account as the documentation
      for strncpy_from_user() cleary states that it "[...] returns the
      length of the string (not including the trailing NUL)" even though the
      null byte will be copied to the destination.
      
      Therefore, subsequent calls to fetch_store_string() will overwrite
      the terminating null byte of the most recently fetched string with
      the first character of the current string, leading to the
      "accumulation" of strings in earlier arguments in the output.
      
      Fix this by incrementing the return value of strncpy_from_user() by
      one if we did not hit the maximum buffer size.
      
      Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 5baaa59e ("tracing/probes: Implement 'memory' fetch method for uprobes")
      Acked-by: 's avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: 's avatarAndreas Ziegler <andreas.ziegler@fau.de>
      Signed-off-by: 's avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: 's avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      137f4db1
    • Meelis Roos's avatar
      alpha: Fix Eiger NR_IRQS to 128 · 5fc95186
      Meelis Roos authored
      commit bfc913682464f45bc4d6044084e370f9048de9d5 upstream.
      
      Eiger machine vector definition has nr_irqs 128, and working 2.6.26
      boot shows SCSI getting IRQ-s 64 and 65. Current kernel boot fails
      because Symbios SCSI fails to request IRQ-s and does not find the disks.
      It has been broken at least since 3.18 - the earliest I could test with
      my gcc-5.
      
      The headers have moved around and possibly another order of defines has
      worked in the past - but since 128 seems to be correct and used, fix
      arch/alpha/include/asm/irq.h to have NR_IRQS=128 for Eiger.
      
      This fixes 4.19-rc7 boot on my Force Flexor A264 (Eiger subarch).
      
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: 's avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: 's avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5fc95186
    • Sergei Trofimovich's avatar
      alpha: fix page fault handling for r16-r18 targets · 1d8b2030
      Sergei Trofimovich authored
      commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
      
      Fix page fault handling code to fixup r16-r18 registers.
      Before the patch code had off-by-two registers bug.
      This bug caused overwriting of ps,pc,gp registers instead
      of fixing intended r16,r17,r18 (see `struct pt_regs`).
      
      More details:
      
      Initially Dmitry noticed a kernel bug as a failure
      on strace test suite. Test passes unmapped userspace
      pointer to io_submit:
      
      ```c
          #include <err.h>
          #include <unistd.h>
          #include <sys/mman.h>
          #include <asm/unistd.h>
          int main(void)
          {
              unsigned long ctx = 0;
              if (syscall(__NR_io_setup, 1, &ctx))
                  err(1, "io_setup");
              const size_t page_size = sysconf(_SC_PAGESIZE);
              const size_t size = page_size * 2;
              void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
                               MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
              if (MAP_FAILED == ptr)
                  err(1, "mmap(%zu)", size);
              if (munmap(ptr, size))
                  err(1, "munmap");
              syscall(__NR_io_submit, ctx, 1, ptr + page_size);
              syscall(__NR_io_destroy, ctx);
              return 0;
          }
      ```
      
      Running this test causes kernel to crash when handling page fault:
      
      ```
          Unable to handle kernel paging request at virtual address ffffffffffff9468
          CPU 3
          aio(26027): Oops 0
          pc = [<fffffc00004eddf8>]  ra = [<fffffc00004edd5c>]  ps = 0000    Not tainted
          pc is at sys_io_submit+0x108/0x200
          ra is at sys_io_submit+0x6c/0x200
          v0 = fffffc00c58e6300  t0 = fffffffffffffff2  t1 = 000002000025e000
          t2 = fffffc01f159fef8  t3 = fffffc0001009640  t4 = fffffc0000e0f6e0
          t5 = 0000020001002e9e  t6 = 4c41564e49452031  t7 = fffffc01f159c000
          s0 = 0000000000000002  s1 = 000002000025e000  s2 = 0000000000000000
          s3 = 0000000000000000  s4 = 0000000000000000  s5 = fffffffffffffff2
          s6 = fffffc00c58e6300
          a0 = fffffc00c58e6300  a1 = 0000000000000000  a2 = 000002000025e000
          a3 = 00000200001ac260  a4 = 00000200001ac1e8  a5 = 0000000000000001
          t8 = 0000000000000008  t9 = 000000011f8bce30  t10= 00000200001ac440
          t11= 0000000000000000  pv = fffffc00006fd320  at = 0000000000000000
          gp = 0000000000000000  sp = 00000000265fd174
          Disabling lock debugging due to kernel taint
          Trace:
          [<fffffc0000311404>] entSys+0xa4/0xc0
      ```
      
      Here `gp` has invalid value. `gp is s overwritten by a fixup for the
      following page fault handler in `io_submit` syscall handler:
      
      ```
          __se_sys_io_submit
          ...
              ldq     a1,0(t1)
              bne     t0,4280 <__se_sys_io_submit+0x180>
      ```
      
      After a page fault `t0` should contain -EFALUT and `a1` is 0.
      Instead `gp` was overwritten in place of `a1`.
      
      This happens due to a off-by-two bug in `dpf_reg()` for `r16-r18`
      (aka `a0-a2`).
      
      I think the bug went unnoticed for a long time as `gp` is one
      of scratch registers. Any kernel function call would re-calculate `gp`.
      
      Dmitry tracked down the bug origin back to 2.1.32 kernel version
      where trap_a{0,1,2} fields were inserted into struct pt_regs.
      And even before that `dpf_reg()` contained off-by-one error.
      
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Reported-and-reviewed-by: 's avatar"Dmitry V. Levin" <ldv@altlinux.org>
      Cc: stable@vger.kernel.org # v2.1.32+
      Bug: https://bugs.gentoo.org/672040Signed-off-by: 's avatarSergei Trofimovich <slyfox@gentoo.org>
      Signed-off-by: 's avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d8b2030
    • Matti Kurkela's avatar
      Input: elantech - enable 3rd button support on Fujitsu CELSIUS H780 · fd08513b
      Matti Kurkela authored
      commit e8b22d0a329f0fb5c7ef95406872d268f01ee3b1 upstream.
      
      Like Fujitsu CELSIUS H760, the H780 also has a three-button Elantech
      touchpad, but the driver needs to be told so to enable the middle touchpad
      button.
      
      The elantech_dmi_force_crc_enabled quirk was not necessary with the H780.
      
      Also document the fw_version and caps values detected for both H760 and
      H780 models.
      Signed-off-by: 's avatarMatti Kurkela <Matti.Kurkela@iki.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd08513b
    • Jonathan Bakker's avatar
      Input: bma150 - register input device after setting private data · 6d6d6255
      Jonathan Bakker authored
      commit 90cc55f067f6ca0e64e5e52883ece47d8af7b67b upstream.
      
      Otherwise we introduce a race condition where userspace can request input
      before we're ready leading to null pointer dereference such as
      
      input: bma150 as /devices/platform/i2c-gpio-2/i2c-5/5-0038/input/input3
      Unable to handle kernel NULL pointer dereference at virtual address 00000018
      pgd = (ptrval)
      [00000018] *pgd=55dac831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] PREEMPT ARM
      Modules linked in: bma150 input_polldev [last unloaded: bma150]
      CPU: 0 PID: 2870 Comm: accelerometer Not tainted 5.0.0-rc3-dirty #46
      Hardware name: Samsung S5PC110/S5PV210-based board
      PC is at input_event+0x8/0x60
      LR is at bma150_report_xyz+0x9c/0xe0 [bma150]
      pc : [<80450f70>]    lr : [<7f0a614c>]    psr: 800d0013
      sp : a4c1fd78  ip : 00000081  fp : 00020000
      r10: 00000000  r9 : a5e2944c  r8 : a7455000
      r7 : 00000016  r6 : 00000101  r5 : a7617940  r4 : 80909048
      r3 : fffffff2  r2 : 00000000  r1 : 00000003  r0 : 00000000
      Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 54e34019  DAC: 00000051
      Process accelerometer (pid: 2870, stack limit = 0x(ptrval))
      Stackck: (0xa4c1fd78 to 0xa4c20000)
      fd60:                                                       fffffff3 fc813f6c
      fd80: 40410581 d7530ce3 a5e2817c a7617f00 a5e29404 a5e2817c 00000000 7f008324
      fda0: a5e28000 8044f59c a5fdd9d0 a5e2945c a46a4a00 a5e29668 a7455000 80454f10
      fdc0: 80909048 a5e29668 a5fdd9d0 a46a4a00 806316d0 00000000 a46a4a00 801df5f0
      fde0: 00000000 d7530ce3 a4c1fec0 a46a4a00 00000000 a5fdd9d0 a46a4a08 801df53c
      fe00: 00000000 801d74bc a4c1fec0 00000000 a4c1ff70 00000000 a7038da8 00000000
      fe20: a46a4a00 801e91fc a411bbe0 801f2e88 00000004 00000000 80909048 00000041
      fe40: 00000000 00020000 00000000 dead4ead a6a88da0 00000000 ffffe000 806fcae8
      fe60: a4c1fec8 00000000 80909048 00000002 a5fdd9d0 a7660110 a411bab0 00000001
      fe80: dead4ead ffffffff ffffffff a4c1fe8c a4c1fe8c d7530ce3 20000013 80909048
      fea0: 80909048 a4c1ff70 00000001 fffff000 a4c1e000 00000005 00026038 801eabd8
      fec0: a7660110 a411bab0 b9394901 00000006 a696201b 76fb3000 00000000 a7039720
      fee0: a5fdd9d0 00000101 00000002 00000096 00000000 00000000 00000000 a4c1ff00
      ff00: a6b310f4 805cb174 a6b310f4 00000010 00000fe0 00000010 a4c1e000 d7530ce3
      ff20: 00000003 a5f41400 a5f41424 00000000 a6962000 00000000 00000003 00000002
      ff40: ffffff9c 000a0000 80909048 d7530ce3 a6962000 00000003 80909048 ffffff9c
      ff60: a6962000 801d890c 00000000 00000000 00020000 a7590000 00000004 00000100
      ff80: 00000001 d7530ce3 000288b8 00026320 000288b8 00000005 80101204 a4c1e000
      ffa0: 00000005 80101000 000288b8 00026320 000288b8 000a0000 00000000 00000000
      ffc0: 000288b8 00026320 000288b8 00000005 7eef3bac 000264e8 00028ad8 00026038
      ffe0: 00000005 7eef3300 76f76e91 76f78546 800d0030 000288b8 00000000 00000000
      [<80450f70>] (input_event) from [<a5e2817c>] (0xa5e2817c)
      Code: e1a08148 eaffffa8 e351001f 812fff1e (e590c018)
      ---[ end trace 1c691ee85f2ff243 ]---
      Signed-off-by: 's avatarJonathan Bakker <xc-racer2@live.ca>
      Signed-off-by: 's avatarPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d6d6255
    • Manuel Reinhardt's avatar
      ALSA: usb-audio: Fix implicit fb endpoint setup by quirk · 05268b5c
      Manuel Reinhardt authored
      commit 2bc16b9f3223d049b57202ee702fcb5b9b507019 upstream.
      
      The commit a60945fd ("ALSA: usb-audio: move implicit fb quirks to
      separate function") introduced an error in the handling of quirks for
      implicit feedback endpoints. This commit fixes this.
      
      If a quirk successfully sets up an implicit feedback endpoint, usb-audio
      no longer tries to find the implicit fb endpoint itself.
      
      Fixes: a60945fd ("ALSA: usb-audio: move implicit fb quirks to separate function")
      Signed-off-by: 's avatarManuel Reinhardt <manuel.rhdt@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05268b5c
    • Jurica Vukadin's avatar
      ALSA: hda - Add quirk for HP EliteBook 840 G5 · 422e1adf
      Jurica Vukadin authored
      commit 4cd3016ce996494f78fdfd87ea35c8ca5d0b413e upstream.
      
      This enables mute LED support and fixes switching jacks when the laptop
      is docked.
      Signed-off-by: 's avatarJurica Vukadin <jurica.vukadin@rt-rk.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      422e1adf
    • Ingo Molnar's avatar
      perf/core: Fix impossible ring-buffer sizes warning · 222b22e1
      Ingo Molnar authored
      commit 528871b456026e6127d95b1b2bd8e3a003dc1614 upstream.
      
      The following commit:
      
        9dff0aa95a32 ("perf/core: Don't WARN() for impossible ring-buffer sizes")
      
      results in perf recording failures with larger mmap areas:
      
        root@skl:/tmp# perf record -g -a
        failed to mmap with 12 (Cannot allocate memory)
      
      The root cause is that the following condition is buggy:
      
      	if (order_base_2(size) >= MAX_ORDER)
      		goto fail;
      
      The problem is that @size is in bytes and MAX_ORDER is in pages,
      so the right test is:
      
      	if (order_base_2(size) >= PAGE_SHIFT+MAX_ORDER)
      		goto fail;
      
      Fix it.
      Reported-by: 's avatar"Jin, Yao" <yao.jin@linux.intel.com>
      Bisected-by: 's avatarBorislav Petkov <bp@alien8.de>
      Analyzed-by: 's avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Julien Thierry <julien.thierry@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      Fixes: 9dff0aa95a32 ("perf/core: Don't WARN() for impossible ring-buffer sizes")
      Signed-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      222b22e1
    • Mauro Ciancio's avatar
      Input: elan_i2c - add ACPI ID for touchpad in Lenovo V330-15ISK · b7febf3b
      Mauro Ciancio authored
      commit 7ad222b3aed350adfc27ee7eec4587ffe55dfdce upstream.
      
      This adds ELAN0617 to the ACPI table to support Elan touchpad found in
      Lenovo V330-15ISK.
      Signed-off-by: 's avatarMauro Ciancio <mauro@acadeu.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7febf3b
    • Dmitry Torokhov's avatar
      Revert "Input: elan_i2c - add ACPI ID for touchpad in ASUS Aspire F5-573G" · d347a894
      Dmitry Torokhov authored
      commit f420c54e4b12c1361c6ed313002ee7bd7ac58362 upstream.
      
      This reverts commit 7db54c89f0b30a101584e09d3729144e6170059d as it
      breaks Acer Aspire V-371 and other devices. According to Elan:
      
      "Acer Aspire F5-573G is MS Precision touchpad which should use hid
       multitouch driver. ELAN0501 should not be added in elan_i2c."
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202503
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d347a894
    • Mark Rustad's avatar
      Documentation/network: reword kernel version reference · 29c84aa9
      Mark Rustad authored
      It seemed odd to say "since 4.17" in a 4.4 kernel. Consider
      rewording the reference to indicate where in the stable series
      it was introduced as well as where it originated.
      Signed-off-by: 's avatarMark Rustad <mrustad@gmail.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      29c84aa9
    • Ross Lagerwall's avatar
      cifs: Limit memory used by lock request calls to a page · 1f39e518
      Ross Lagerwall authored
      [ Upstream commit 92a8109e4d3a34fb6b115c9098b51767dc933444 ]
      
      The code tries to allocate a contiguous buffer with a size supplied by
      the server (maxBuf). This could fail if memory is fragmented since it
      results in high order allocations for commonly used server
      implementations. It is also wasteful since there are probably
      few locks in the usual case. Limit the buffer to be no larger than a
      page to avoid memory allocation failures due to fragmentation.
      Signed-off-by: 's avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: 's avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      1f39e518
    • Nicholas Mc Guire's avatar
      gpio: pl061: handle failed allocations · 83476701
      Nicholas Mc Guire authored
      [ Upstream commit df209c43a0e8258e096fb722dfbdae4f0dd13fde ]
      
      devm_kzalloc(), devm_kstrdup() and devm_kasprintf() all can
      fail internal allocation and return NULL. Using any of the assigned
      objects without checking is not safe. As this is early in the boot
      phase and these allocations really should not fail, any failure here
      is probably an indication of a more serious issue so it makes little
      sense to try and rollback the previous allocated resources or try to
      continue;  but rather the probe function is simply exited with -ENOMEM.
      Signed-off-by: 's avatarNicholas Mc Guire <hofrat@osadl.org>
      Fixes: 684284b6 ("ARM: integrator: add MMCI device to IM-PD1")
      Signed-off-by: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      83476701
    • Linus Walleij's avatar
      ARM: dts: kirkwood: Fix polarity of GPIO fan lines · 32f04710
      Linus Walleij authored
      [ Upstream commit b5f034845e70916fd33e172fad5ad530a29c10ab ]
      
      These two lines are active high, not active low. The bug was
      found when we changed the kernel to respect the polarity defined
      in the device tree.
      
      Fixes: 1b90e06b ("ARM: kirkwood: Use devicetree to define DNS-32[05] fan")
      Cc: Jamie Lentin <jm@lentin.co.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@bootlin.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Julien D'Ascenzio <jdascenzio@posteo.net>
      Reviewed-by: 's avatarAndrew Lunn <andrew@lunn.ch>
      Tested-by: 's avatarJamie Lentin <jm@lentin.co.uk>
      Reported-by: 's avatarJulien D'Ascenzio <jdascenzio@posteo.net>
      Tested-by: 's avatarJulien D'Ascenzio <jdascenzio@posteo.net>
      Signed-off-by: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: 's avatarGregory CLEMENT <gregory.clement@bootlin.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      32f04710
    • Peter Ujfalusi's avatar
      ARM: dts: da850-evm: Correct the sound card name · 20ad5046
      Peter Ujfalusi authored
      [ Upstream commit 7fca69d4e43fa1ae9cb4f652772c132dc5a659c6 ]
      
      To avoid  the following error:
      asoc-simple-card sound: ASoC: Failed to create card debugfs directory
      
      Which is because the card name contains '/' character, which can not be
      used in file or directory names.
      Signed-off-by: 's avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: 's avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      20ad5046
    • Hauke Mehrtens's avatar
      uapi/if_ether.h: prevent redefinition of struct ethhdr · 28b5d0be
      Hauke Mehrtens authored
      commit 6926e041 upstream.
      
      Musl provides its own ethhdr struct definition. Add a guard to prevent
      its definition of the appropriate musl header has already been included.
      
      glibc does not implement this header, but when glibc will implement this
      they can just define __UAPI_DEF_ETHHDR 0 to make it work with the
      kernel.
      Signed-off-by: 's avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      28b5d0be
    • Linus Torvalds's avatar
      Revert "exec: load_script: don't blindly truncate shebang string" · 7cbbbf75
      Linus Torvalds authored
      commit cb5b020a8d38f77209d0472a0fea755299a8ec78 upstream.
      
      This reverts commit 8099b047ecc431518b9bb6bdbba3549bbecdc343.
      
      It turns out that people do actually depend on the shebang string being
      truncated, and on the fact that an interpreter (like perl) will often
      just re-interpret it entirely to get the full argument list.
      Reported-by: 's avatarSamuel Dionne-Riel <samuel@dionne-riel.com>
      Acked-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cbbbf75
    • Sven Eckelmann's avatar
      batman-adv: Force mac header to start of data on xmit · b2942d59
      Sven Eckelmann authored
      commit 9114daa825fc3f335f9bea3313ce667090187280 upstream.
      
      The caller of ndo_start_xmit may not already have called
      skb_reset_mac_header. The returned value of skb_mac_header/eth_hdr
      therefore can be in the wrong position and even outside the current skbuff.
      This for example happens when the user binds to the device using a
      PF_PACKET-SOCK_RAW with enabled qdisc-bypass:
      
        int opt = 4;
        setsockopt(sock, SOL_PACKET, PACKET_QDISC_BYPASS, &opt, sizeof(opt));
      
      Since eth_hdr is used all over the codebase, the batadv_interface_tx
      function must always take care of resetting it.
      
      Fixes: c6c8fea2 ("net: Add batman-adv meshing protocol")
      Reported-by: syzbot+9d7405c7faa390e60b4e@syzkaller.appspotmail.com
      Reported-by: syzbot+7d20bc3f1ddddc0f9079@syzkaller.appspotmail.com
      Signed-off-by: 's avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: 's avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2942d59
    • Sven Eckelmann's avatar
      batman-adv: Avoid WARN on net_device without parent in netns · 8fe16146
      Sven Eckelmann authored
      commit 955d3411a17f590364238bd0d3329b61f20c1cd2 upstream.
      
      It is not allowed to use WARN* helpers on potential incorrect input from
      the user or transient problems because systems configured as panic_on_warn
      will reboot due to such a problem.
      
      A NULL return value of __dev_get_by_index can be caused by various problems
      which can either be related to the system configuration or problems
      (incorrectly returned network namespaces) in other (virtual) net_device
      drivers. batman-adv should not cause a (harmful) WARN in this situation and
      instead only report it via a simple message.
      
      Fixes: b7eddd0b ("batman-adv: prevent using any virtual device created on batman-adv as hard-interface")
      Reported-by: syzbot+c764de0fcfadca9a8595@syzkaller.appspotmail.com
      Reported-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: 's avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: 's avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8fe16146
    • Florian Westphal's avatar
      xfrm: refine validation of template and selector families · ca6fd8df
      Florian Westphal authored
      commit 35e6103861a3a970de6c84688c6e7a1f65b164ca upstream.
      
      The check assumes that in transport mode, the first templates family
      must match the address family of the policy selector.
      
      Syzkaller managed to build a template using MODE_ROUTEOPTIMIZATION,
      with ipv4-in-ipv6 chain, leading to following splat:
      
      BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x1db/0x1854
      Read of size 4 at addr ffff888063e57aa0 by task a.out/2050
       xfrm_state_find+0x1db/0x1854
       xfrm_tmpl_resolve+0x100/0x1d0
       xfrm_resolve_and_create_bundle+0x108/0x1000 [..]
      
      Problem is that addresses point into flowi4 struct, but xfrm_state_find
      treats them as being ipv6 because it uses templ->encap_family is used
      (AF_INET6 in case of reproducer) rather than family (AF_INET).
      
      This patch inverts the logic: Enforce 'template family must match
      selector' EXCEPT for tunnel and BEET mode.
      
      In BEET and Tunnel mode, xfrm_tmpl_resolve_one will have remote/local
      address pointers changed to point at the addresses found in the template,
      rather than the flowi ones, so no oob read will occur.
      
      Reported-by: 3ntr0py1337@gmail.com
      Reported-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: 's avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca6fd8df
    • Ilya Dryomov's avatar
      libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive() · 2e9e4e15
      Ilya Dryomov authored
      commit 4aac9228d16458cedcfd90c7fb37211cf3653ac3 upstream.
      
      con_fault() can transition the connection into STANDBY right after
      ceph_con_keepalive() clears STANDBY in clear_standby():
      
          libceph user thread               ceph-msgr worker
      
      ceph_con_keepalive()
        mutex_lock(&con->mutex)
        clear_standby(con)
        mutex_unlock(&con->mutex)
                                      mutex_lock(&con->mutex)
                                      con_fault()
                                        ...
                                        if KEEPALIVE_PENDING isn't set
                                          set state to STANDBY
                                        ...
                                      mutex_unlock(&con->mutex)
        set KEEPALIVE_PENDING
        set WRITE_PENDING
      
      This triggers warnings in clear_standby() when either ceph_con_send()
      or ceph_con_keepalive() get to clearing STANDBY next time.
      
      I don't see a reason to condition queue_con() call on the previous
      value of KEEPALIVE_PENDING, so move the setting of KEEPALIVE_PENDING
      into the critical section -- unlike WRITE_PENDING, KEEPALIVE_PENDING
      could have been a non-atomic flag.
      
      Reported-by: syzbot+acdeb633f6211ccdf886@syzkaller.appspotmail.com
      Signed-off-by: 's avatarIlya Dryomov <idryomov@gmail.com>
      Tested-by: 's avatarMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e9e4e15
    • Greg Kroah-Hartman's avatar
      Revert "cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)" · 1793dc65
      Greg Kroah-Hartman authored
      This reverts commit 60da90b2 which is
      commit 6e785302dad32228819d8066e5376acd15d0e6ba upstream.
      
      Yi writes:
      	I notice that 4.4.169 merged 60da90b2 ("cifs: In Kconfig
      	CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)") add
      	a Kconfig dependency CIFS_ALLOW_INSECURE_LEGACY, which was not
      	defined in 4.4 stable, so after this patch we are not able to
      	enable CIFS_POSIX anymore. Linux 4.4 stable didn't merge the
      	legacy dialects codes, so do we really need this patch for 4.4?
      
      So revert this patch.
      Reported-by: 's avatar"zhangyi (F)" <yi.zhang@huawei.com>
      Cc: Steve French <stfrench@microsoft.com>
      Cc: Pavel Shilovsky <pshilov@microsoft.com>
      Cc: Sasha Levin <sashal@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1793dc65
    • Guenter Roeck's avatar
      NFC: nxp-nci: Include unaligned.h instead of access_ok.h · 2a41ed30
      Guenter Roeck authored
      commit 2eee74b7 upstream.
      
      Directly including access_ok.h can result in the following compile errors
      if an architecture such as ia64 does not support direct unaligned accesses.
      
      include/linux/unaligned/access_ok.h:7:19: error:
      	redefinition of 'get_unaligned_le16'
      include/linux/unaligned/le_struct.h:6:19: note:
      	previous definition of 'get_unaligned_le16' was here
      include/linux/unaligned/access_ok.h:12:19: error:
      	redefinition of 'get_unaligned_le32'
      include/linux/unaligned/le_struct.h:11:19: note:
      	previous definition of 'get_unaligned_le32' was here
      
      Include asm/unaligned.h instead and let the architecture decide which
      access functions to use.
      
      Cc: Clément Perrochaud <clement.perrochaud@effinnov.com>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: 's avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: 's avatarSamuel Ortiz <sameo@linux.intel.com>
      Cc: Matthias Kaehlcke <mka@chromium.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a41ed30
    • Vladis Dronov's avatar
      HID: debug: fix the ring buffer implementation · b661fff5
      Vladis Dronov authored
      commit 13054abbaa4f1fd4e6f3b4b63439ec033b4c8035 upstream.
      
      Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
      is strange allowing lost or corrupted data. After commit 717adfdaf147
      ("HID: debug: check length before copy_to_user()") it is possible to enter
      an infinite loop in hid_debug_events_read() by providing 0 as count, this
      locks up a system. Fix this by rewriting the ring buffer implementation
      with kfifo and simplify the code.
      
      This fixes CVE-2019-3819.
      
      v2: fix an execution logic and add a comment
      v3: use __set_current_state() instead of set_current_state()
      
      Backport to v4.4: some (tree-wide) patches are missing in v4.4 so
      cherry-pick relevant pieces from:
       * 6396bb22151 ("treewide: kzalloc() -> kcalloc()")
       * a9a08845 ("vfs: do bulk POLL* -> EPOLL* replacement")
       * 92529623 ("HID: debug: improve hid_debug_event()")
       * 174cd4b1 ("sched/headers: Prepare to move signal wakeup & sigpending
         methods from <linux/sched.h> into <linux/sched/signal.h>")
      
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
      Cc: stable@vger.kernel.org # v4.18+
      Fixes: cd667ce2 ("HID: use debugfs for events/reports dumping")
      Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()")
      Signed-off-by: 's avatarVladis Dronov <vdronov@redhat.com>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: 's avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b661fff5
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user · 697c6f72
      Thomas Hellstrom authored
      commit 728354c005c36eaf44b6e5552372b67e60d17f56 upstream.
      
      The function was unconditionally returning 0, and a caller would have to
      rely on the returned fence pointer being NULL to detect errors. However,
      the function vmw_execbuf_copy_fence_user() would expect a non-zero error
      code in that case and would BUG otherwise.
      
      So make sure we return a proper non-zero error code if the fence pointer
      returned is NULL.
      
      Cc: <stable@vger.kernel.org>
      Fixes: ae2a1040: ("vmwgfx: Implement fence objects")
      Signed-off-by: 's avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: 's avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      697c6f72
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Fix setting of dma masks · 6bcca0bc
      Thomas Hellstrom authored
      commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
      
      Previously we set only the dma mask and not the coherent mask. Fix that.
      Also, for clarity, make sure both are initially set to 64 bits.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 0d00c488: ("drm/vmwgfx: Fix the driver for large dma addresses")
      Signed-off-by: 's avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: 's avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bcca0bc
    • Tina Zhang's avatar
      drm/modes: Prevent division by zero htotal · f1cd557e
      Tina Zhang authored
      commit a2fcd5c84f7a7825e028381b10182439067aa90d upstream.
      
      This patch prevents division by zero htotal.
      
      In a follow-up mail Tina writes:
      
      > > How did you manage to get here with htotal == 0? This needs backtraces (or if
      > > this is just about static checkers, a mention of that).
      > > -Daniel
      >
      > In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
      > (a.k.a htotal=0), then we met the following kernel panic:
      >
      > [   32.832048] divide error: 0000 [#1] SMP PTI
      > [   32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
      > [   32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
      > [   32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.836004] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.836004] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.836004] Call Trace:
      > [   32.836004]  intel_mode_from_pipe_config+0x72/0x90
      > [   32.836004]  intel_modeset_setup_hw_state+0x569/0xf90
      > [   32.836004]  intel_modeset_init+0x905/0x1db0
      > [   32.836004]  i915_driver_load+0xb8c/0x1120
      > [   32.836004]  i915_pci_probe+0x4d/0xb0
      > [   32.836004]  local_pci_probe+0x44/0xa0
      > [   32.836004]  ? pci_assign_irq+0x27/0x130
      > [   32.836004]  pci_device_probe+0x102/0x1c0
      > [   32.836004]  driver_probe_device+0x2b8/0x480
      > [   32.836004]  __driver_attach+0x109/0x110
      > [   32.836004]  ? driver_probe_device+0x480/0x480
      > [   32.836004]  bus_for_each_dev+0x67/0xc0
      > [   32.836004]  ? klist_add_tail+0x3b/0x70
      > [   32.836004]  bus_add_driver+0x1e8/0x260
      > [   32.836004]  driver_register+0x5b/0xe0
      > [   32.836004]  ? mipi_dsi_bus_init+0x11/0x11
      > [   32.836004]  do_one_initcall+0x4d/0x1eb
      > [   32.836004]  kernel_init_freeable+0x197/0x237
      > [   32.836004]  ? rest_init+0xd0/0xd0
      > [   32.836004]  kernel_init+0xa/0x110
      > [   32.836004]  ret_from_fork+0x35/0x40
      > [   32.836004] Modules linked in:
      > [   32.859183] ---[ end trace 525608b0ed0e8665 ]---
      > [   32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.868075] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.868983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      >
      > Since drm_mode_hsync() has the logic to check mode->htotal, I just extend it to cover the case htotal==0.
      Signed-off-by: 's avatarTina Zhang <tina.zhang@intel.com>
      Cc: Adam Jackson <ajax@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      [danvet: Add additional explanations + cc: stable.]
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1cd557e
    • Felix Fietkau's avatar
      mac80211: ensure that mgmt tx skbs have tailroom for encryption · 06288a8e
      Felix Fietkau authored
      commit 9d0f50b80222dc273e67e4e14410fcfa4130a90c upstream.
      
      Some drivers use IEEE80211_KEY_FLAG_SW_MGMT_TX to indicate that management
      frames need to be software encrypted. Since normal data packets are still
      encrypted by the hardware, crypto_tx_tailroom_needed_cnt gets decremented
      after key upload to hw. This can lead to passing skbs to ccmp_encrypt_skb,
      which don't have the necessary tailroom for software encryption.
      
      Change the code to add tailroom for encrypted management packets, even if
      crypto_tx_tailroom_needed_cnt is 0.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: 's avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06288a8e
    • Russell King's avatar
      ARM: iop32x/n2100: fix PCI IRQ mapping · fd9d0553
      Russell King authored
      commit db4090920ba2d61a5827a23e441447926a02ffee upstream.
      
      Booting 4.20 on a TheCUS N2100 results in a kernel oops while probing
      PCI, due to n2100_pci_map_irq() having been discarded during boot.
      Signed-off-by: 's avatarRussell King <rmk+kernel@armlinux.org.uk>
      Cc: stable@vger.kernel.org # 2.6.18+
      Signed-off-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd9d0553
    • Paul Burton's avatar
      MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds · dfb35362
      Paul Burton authored
      commit 67fc5dc8a541e8f458d7f08bf88ff55933bf9f9d upstream.
      
      When generating vdso-o32.lds & vdso-n32.lds for use with programs
      running as compat ABIs under 64b kernels, we previously haven't included
      the compiler flags that are supposedly common to all ABIs - ie. those in
      the ccflags-vdso variable.
      
      This is problematic in cases where we need to provide the -m%-float flag
      in order to ensure that we don't attempt to use a floating point ABI
      that's incompatible with the target CPU & ABI. For example a toolchain
      using current gcc trunk configured --with-fp-32=xx fails to build a
      64r6el_defconfig kernel with the following error:
      
        cc1: error: '-march=mips1' requires '-mfp32'
        make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1
      
      Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
      included for the native VDSO .lds & when compiling objects for the
      compat VDSOs. This ensures we consistently provide the -msoft-float flag
      amongst others, avoiding the problem by ensuring we're agnostic to the
      toolchain defaults.
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
      Cc: linux-mips@vger.kernel.org
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Maciej W . Rozycki <macro@linux-mips.org>
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfb35362
    • Aaro Koskinen's avatar
      MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled · 91aaa0dd
      Aaro Koskinen authored
      commit dcf300a69ac307053dfb35c2e33972e754a98bce upstream.
      
      Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation
      of the MSI irqchip later on, and saves a bit of memory.
      Signed-off-by: 's avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Fixes: a214720cbf50 ("Disable MSI also when pcie-octeon.pcie_disable on")
      Cc: stable@vger.kernel.org # v3.3+
      Cc: linux-mips@vger.kernel.org
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91aaa0dd
    • Vladimir Kondratiev's avatar
      mips: cm: reprime error cause · d93fdf44
      Vladimir Kondratiev authored
      commit 05dc6001af0630e200ad5ea08707187fe5537e6d upstream.
      
      Accordingly to the documentation
      ---cut---
      The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
      fields can be cleared by either a reset or by writing the current
      value of GCR_ERROR_CAUSE.ERR_TYPE to the
      GCR_ERROR_CAUSE.ERR_TYPE register.
      ---cut---
      Do exactly this. Original value of cm_error may be safely written back;
      it clears error cause and keeps other bits untouched.
      
      Fixes: 3885c2b4 ("MIPS: CM: Add support for reporting CM cache errors")
      Signed-off-by: 's avatarVladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
      Signed-off-by: 's avatarPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.3+
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d93fdf44
    • Greg Kroah-Hartman's avatar
      debugfs: fix debugfs_rename parameter checking · 2b46cd1a
      Greg Kroah-Hartman authored
      commit d88c93f090f708c18195553b352b9f205e65418f upstream.
      
      debugfs_rename() needs to check that the dentries passed into it really
      are valid, as sometimes they are not (i.e. if the return value of
      another debugfs call is passed into this one.)  So fix this up by
      properly checking if the two parent directories are errors (they are
      allowed to be NULL), and if the dentry to rename is not NULL or an
      error.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b46cd1a
    • Dan Carpenter's avatar
      misc: vexpress: Off by one in vexpress_syscfg_exec() · 99b23b0d
      Dan Carpenter authored
      commit f8a70d8b889f180e6860cb1f85fed43d37844c5a upstream.
      
      The > comparison should be >= to prevent reading beyond the end of the
      func->template[] array.
      
      (The func->template array is allocated in vexpress_syscfg_regmap_init()
      and it has func->num_templates elements.)
      
      Fixes: 974cc7b9 ("mfd: vexpress: Define the device as MFD cells")
      Signed-off-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: 's avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99b23b0d
    • Eric W. Biederman's avatar
      signal: Better detection of synchronous signals · 60de9fff
      Eric W. Biederman authored
      commit 7146db3317c67b517258cb5e1b08af387da0618b upstream.
      
      Recently syzkaller was able to create unkillablle processes by
      creating a timer that is delivered as a thread local signal on SIGHUP,
      and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop failing
      to deliver SIGHUP but always trying.
      
      When the stack overflows delivery of SIGHUP fails and force_sigsegv is
      called.  Unfortunately because SIGSEGV is numerically higher than
      SIGHUP next_signal tries again to deliver a SIGHUP.
      
      From a quality of implementation standpoint attempting to deliver the
      timer SIGHUP signal is wrong.  We should attempt to deliver the
      synchronous SIGSEGV signal we just forced.
      
      We can make that happening in a fairly straight forward manner by
      instead of just looking at the signal number we also look at the
      si_code.  In particular for exceptions (aka synchronous signals) the
      si_code is always greater than 0.
      
      That still has the potential to pick up a number of asynchronous
      signals as in a few cases the same si_codes that are used
      for synchronous signals are also used for asynchronous signals,
      and SI_KERNEL is also included in the list of possible si_codes.
      
      Still the heuristic is much better and timer signals are definitely
      excluded.  Which is enough to prevent all known ways for someone
      sending a process signals fast enough to cause unexpected and
      arguably incorrect behavior.
      
      Cc: stable@vger.kernel.org
      Fixes: a27341cd ("Prioritize synchronous signals over 'normal' signals")
      Tested-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Reported-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: 's avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60de9fff
    • Eric W. Biederman's avatar
      signal: Always notice exiting tasks · 381fc509
      Eric W. Biederman authored
      commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.
      
      Recently syzkaller was able to create unkillablle processes by
      creating a timer that is delivered as a thread local signal on SIGHUP,
      and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
      failing to deliver SIGHUP but always trying.
      
      Upon examination it turns out part of the problem is actually most of
      the solution.  Since 2.5 signal delivery has found all fatal signals,
      marked the signal group for death, and queued SIGKILL in every threads
      thread queue relying on signal->group_exit_code to preserve the
      information of which was the actual fatal signal.
      
      The conversion of all fatal signals to SIGKILL results in the
      synchronous signal heuristic in next_signal kicking in and preferring
      SIGHUP to SIGKILL.  Which is especially problematic as all
      fatal signals have already been transformed into SIGKILL.
      
      Instead of dequeueing signals and depending upon SIGKILL to
      be the first signal dequeued, first test if the signal group
      has already been marked for death.  This guarantees that
      nothing in the signal queue can prevent a process that needs
      to exit from exiting.
      
      Cc: stable@vger.kernel.org
      Tested-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Reported-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
      History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.gitSigned-off-by: 's avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      381fc509
    • Martin Kepplinger's avatar
      mtd: rawnand: gpmi: fix MX28 bus master lockup problem · 6f17dfe5
      Martin Kepplinger authored
      commit d5d27fd9826b59979b184ec288e4812abac0e988 upstream.
      
      Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft
      reset may cause bus master lock up") for MX28 too. It has the same
      problem.
      
      Observed problem: once per 100,000+ MX28 reboots NAND read failed on
      DMA timeout errors:
      [    1.770823] UBI: attaching mtd3 to ubi0
      [    2.768088] gpmi_nand: DMA timeout, last DMA :1
      [    3.958087] gpmi_nand: BCH timeout, last DMA :1
      [    4.156033] gpmi_nand: Error in ECC-based read: -110
      [    4.161136] UBI warning: ubi_io_read: error -110 while reading 64
      bytes from PEB 0:0, read only 0 bytes, retry
      [    4.171283] step 1 error
      [    4.173846] gpmi_nand: Chip: 0, Error -1
      
      Without BCH soft reset we successfully executed 1,000,000 MX28 reboots.
      
      I have a quote from NXP regarding this problem, from July 18th 2016:
      
      "As the i.MX23 and i.MX28 are of the same generation, they share many
      characteristics. Unfortunately, also the erratas may be shared.
      In case of the documented erratas and the workarounds, you can also
      apply the workaround solution of one device on the other one. This have
      been reported, but I’m afraid that there are not an estimated date for
      updating the Errata documents.
      Please accept our apologies for any inconveniences this may cause."
      
      Fixes: 6f2a6a52 ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems")
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarManfred Schlaegl <manfred.schlaegl@ginzinger.com>
      Signed-off-by: 's avatarMartin Kepplinger <martin.kepplinger@ginzinger.com>
      Reviewed-by: 's avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Reviewed-by: 's avatarFabio Estevam <festevam@gmail.com>
      Acked-by: 's avatarHan Xu <han.xu@nxp.com>
      Signed-off-by: 's avatarBoris Brezillon <bbrezillon@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f17dfe5
    • Gustavo A. R. Silva's avatar
      perf tests evsel-tp-sched: Fix bitwise operator · cb7c96ee
      Gustavo A. R. Silva authored
      commit 489338a717a0dfbbd5a3fabccf172b78f0ac9015 upstream.
      
      Notice that the use of the bitwise OR operator '|' always leads to true
      in this particular case, which seems a bit suspicious due to the context
      in which this expression is being used.
      
      Fix this by using bitwise AND operator '&' instead.
      
      This bug was detected with the help of Coccinelle.
      Signed-off-by: 's avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Acked-by: 's avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Fixes: 6a6cd11d ("perf test: Add test for the sched tracepoint format fields")
      Link: http://lkml.kernel.org/r/20190122233439.GA5868@embeddedorSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb7c96ee