1. 08 Dec, 2018 3 commits
  2. 05 Dec, 2018 37 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.143 · b136f0e9
      Greg Kroah-Hartman authored
      b136f0e9
    • Chris Fries's avatar
      kbuild: Set KBUILD_CFLAGS before incl. arch Makefile · 740f140b
      Chris Fries authored
      (commit ae6b289a upstream)
      
      Set the clang KBUILD_CFLAGS up before including arch/ Makefiles,
      so that ld-options (etc.) can work correctly.
      
      This fixes errors with clang such as ld-options trying to CC
      against your host architecture, but LD trying to link against
      your target architecture.
      Signed-off-by: default avatarChris Fries <cfries@google.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Tested-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      [ND: adjusted context due to upstream having removed code above where I
      placed this block in this backport]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      740f140b
    • Ard Biesheuvel's avatar
      efi/libstub: Make file I/O chunking x86-specific · 6d075d21
      Ard Biesheuvel authored
      (commit b3879a4d upstream)
      
      The ARM decompressor is finicky when it comes to uninitialized variables
      with local linkage, the reason being that it may relocate .text and .bss
      independently when executing from ROM. This is only possible if all
      references into .bss from .text are absolute, and this happens to be the
      case for references emitted under -fpic to symbols with external linkage,
      and so all .bss references must involve symbols with external linkage.
      
      When building the ARM stub using clang, the initialized local variable
      __chunk_size is optimized into a zero-initialized flag that indicates
      whether chunking is in effect or not. This flag is therefore emitted into
      .bss, which triggers the ARM decompressor's diagnostics, resulting in a
      failed build.
      
      Under UEFI, we never execute the decompressor from ROM, so the diagnostic
      makes little sense here. But we can easily work around the issue by making
      __chunk_size global instead.
      
      However, given that the file I/O chunking that is controlled by the
      __chunk_size variable is intended to work around known bugs on various
      x86 implementations of UEFI, we can simply make the chunking an x86
      specific feature. This is an improvement by itself, and also removes the
      need to parse the efi= options in the stub entirely.
      Tested-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1486380166-31868-8-git-send-email-ard.biesheuvel@linaro.org
      [ Small readability edits. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d075d21
    • Arnd Bergmann's avatar
      workqueue: avoid clang warning · 6f35b5bd
      Arnd Bergmann authored
      (commit a45463cb upstream)
      
      Building with clang shows lots of warning like:
      
      drivers/amba/bus.c:447:8: warning: implicit conversion from 'long long' to 'int' changes value from 4294967248 to -48
            [-Wconstant-conversion]
      static DECLARE_DELAYED_WORK(deferred_retry_work, amba_deferred_retry_func);
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      include/linux/workqueue.h:187:26: note: expanded from macro 'DECLARE_DELAYED_WORK'
              struct delayed_work n = __DELAYED_WORK_INITIALIZER(n, f, 0)
                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      include/linux/workqueue.h:177:10: note: expanded from macro '__DELAYED_WORK_INITIALIZER'
              .work = __WORK_INITIALIZER((n).work, (f)),                      \
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      include/linux/workqueue.h:170:10: note: expanded from macro '__WORK_INITIALIZER'
              .data = WORK_DATA_STATIC_INIT(),                                \
                      ^~~~~~~~~~~~~~~~~~~~~~~
      include/linux/workqueue.h:111:39: note: expanded from macro 'WORK_DATA_STATIC_INIT'
              ATOMIC_LONG_INIT(WORK_STRUCT_NO_POOL | WORK_STRUCT_STATIC)
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
      include/asm-generic/atomic-long.h:32:41: note: expanded from macro 'ATOMIC_LONG_INIT'
       #define ATOMIC_LONG_INIT(i)     ATOMIC_INIT(i)
                                      ~~~~~~~~~~~~^~
      arch/arm/include/asm/atomic.h:21:27: note: expanded from macro 'ATOMIC_INIT'
       #define ATOMIC_INIT(i)  { (i) }
                              ~  ^
      
      This makes the type cast explicit, which shuts up the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f35b5bd
    • Stefan Agner's avatar
      ARM: trusted_foundations: do not use naked function · 1e5b5cb7
      Stefan Agner authored
      (commit 4ea7bdc6b5b33427bbd3f41c333e21c1825462a3 upstream)
      
      As documented in GCC naked functions should only use basic ASM
      syntax. The extended ASM or mixture of basic ASM and "C" code is
      not guaranteed. Currently this works because it was hard coded
      to follow and check GCC behavior for arguments and register
      placement.
      
      Furthermore with clang using parameters in Extended asm in a
      naked function is not supported:
        arch/arm/firmware/trusted_foundations.c:47:10: error: parameter
                references not allowed in naked functions
                      : "r" (type), "r" (arg1), "r" (arg2)
                             ^
      
      Use a regular function to be more portable. This aligns also with
      the other SMC call implementations e.g. in qcom_scm-32.c and
      bcm_kona_smc.c.
      
      Cc: Dmitry Osipenko <digetx@gmail.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e5b5cb7
    • Stefan Agner's avatar
      bus: arm-cci: remove unnecessary unreachable() · b874a875
      Stefan Agner authored
      (commit 10d8713429d345867fc8998d6193b233c0cab28c upstream)
      
      Mixing asm and C code is not recommended in a naked function by
      gcc and leads to an error when using clang:
        drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked
        function is not supported
              unreachable();
              ^
      
      While the function is marked __naked it actually properly return
      in asm. There is no need for the unreachable() call.
      
      GCC 7.2 generates identical object files before and after, other
      than (for obvious reasons) the line numbers generated by
      WANT_WARN_ON_SLOWPATH for all the WARN()s appearing later in the
      file.
      Suggested-by: default avatarRussell King <linux@arm.linux.org.uk>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b874a875
    • Stefan Agner's avatar
      ARM: 8767/1: add support for building ARM kernel with clang · 10479075
      Stefan Agner authored
      (commit c1c386681bd73c4fc28eb5cc91cf8b7be9b409ba upstream)
      
      Use cc-options call for compiler options which are not available
      in clang. With this patch an ARMv7 multi platform kernel can be
      successfully build using clang (tested with version 5.0.1).
      Based-on-patches-by: default avatarBehan Webster <behanw@converseincode.com>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10479075
    • Stefan Agner's avatar
      ARM: 8766/1: drop no-thumb-interwork in EABI mode · 61cc8587
      Stefan Agner authored
      (commit 22905a24306c8c312c2d66da9f90d09af0414f81 upstream)
      
      According to GCC documentation -m(no-)thumb-interwork is
      meaningless in AAPCS configurations. Also clang does not
      support the flag:
        clang-5.0: error: unknown argument: '-mno-thumb-interwork'
      
      Just drop -mno-thumb-interwork in AEABI configuration.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61cc8587
    • Alistair Strachan's avatar
      efi/libstub: arm: support building with clang · fb660794
      Alistair Strachan authored
      (commit 41f1c48420709470c51ee0e54b6fb28b956bb4e0 upstream)
      
      When building with CONFIG_EFI and CONFIG_EFI_STUB on ARM, the libstub
      Makefile would use -mno-single-pic-base without checking it was
      supported by the compiler. As the ARM (32-bit) clang backend does not
      support this flag, the build would fail.
      
      This changes the Makefile to check the compiler's support for
      -mno-single-pic-base before using it, similar to c1c386681bd7 ("ARM:
      8767/1: add support for building ARM kernel with clang").
      Signed-off-by: default avatarAlistair Strachan <astrachan@google.com>
      Reviewed-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [ND: adjusted due to missing commit ce279d374ff3 ("efi/libstub:
       Only disable stackleak plugin for arm64")]
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb660794
    • YueHaibing's avatar
      misc: mic/scif: fix copy-paste error in scif_create_remote_lookup · c4c29e1b
      YueHaibing authored
      commit 6484a677294aa5d08c0210f2f387ebb9be646115 upstream.
      
      gcc '-Wunused-but-set-variable' warning:
      
      drivers/misc/mic/scif/scif_rma.c: In function 'scif_create_remote_lookup':
      drivers/misc/mic/scif/scif_rma.c:373:25: warning:
       variable 'vmalloc_num_pages' set but not used [-Wunused-but-set-variable]
      
      'vmalloc_num_pages' should be used to determine if the address is
      within the vmalloc range.
      
      Fixes: ba612aa8 ("misc: mic: SCIF memory registration and unregistration")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4c29e1b
    • Dexuan Cui's avatar
      Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl() · 140ee9b7
      Dexuan Cui authored
      commit eceb05965489784f24bbf4d61ba60e475a983016 upstream.
      
      This is a longstanding issue: if the vmbus upper-layer drivers try to
      consume too many GPADLs, the host may return with an error
      0xC0000044 (STATUS_QUOTA_EXCEEDED), but currently we forget to check
      the creation_status, and hence we can pass an invalid GPADL handle
      into the OPEN_CHANNEL message, and get an error code 0xc0000225 in
      open_info->response.open_result.status, and finally we hang in
      vmbus_open() -> "goto error_free_info" -> vmbus_teardown_gpadl().
      
      With this patch, we can exit gracefully on STATUS_QUOTA_EXCEEDED.
      
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      140ee9b7
    • Yu Zhao's avatar
      mm: use swp_offset as key in shmem_replace_page() · 3c470638
      Yu Zhao authored
      commit c1cb20d43728aa9b5393bd8d489bc85c142949b2 upstream.
      
      We changed the key of swap cache tree from swp_entry_t.val to
      swp_offset.  We need to do so in shmem_replace_page() as well.
      
      Hugh said:
       "shmem_replace_page() has been wrong since the day I wrote it: good
        enough to work on swap "type" 0, which is all most people ever use
        (especially those few who need shmem_replace_page() at all), but
        broken once there are any non-0 swp_type bits set in the higher order
        bits"
      
      Link: http://lkml.kernel.org/r/20181121215442.138545-1-yuzhao@google.com
      Fixes: f6ab1f7f ("mm, swap: use offset of swap entry as key of swap cache")
      Signed-off-by: default avatarYu Zhao <yuzhao@google.com>
      Reviewed-by: default avatarMatthew Wilcox <willy@infradead.org>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>	[4.9+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c470638
    • Martin Kelly's avatar
      iio:st_magn: Fix enable device after trigger · 06c2233a
      Martin Kelly authored
      commit fe5192ac81ad0d4dfe1395d11f393f0513c15f7f upstream.
      
      Currently, we enable the device before we enable the device trigger. At
      high frequencies, this can cause interrupts that don't yet have a poll
      function associated with them and are thus treated as spurious. At high
      frequencies with level interrupts, this can even cause an interrupt storm
      of repeated spurious interrupts (~100,000 on my Beagleboard with the
      LSM9DS1 magnetometer). If these repeat too much, the interrupt will get
      disabled and the device will stop functioning.
      
      To prevent these problems, enable the device prior to enabling the device
      trigger, and disable the divec prior to disabling the trigger. This means
      there's no window of time during which the device creates interrupts but we
      have no trigger to answer them.
      
      Fixes: 90efe055 ("iio: st_sensors: harden interrupt handling")
      Signed-off-by: default avatarMartin Kelly <martin@martingkelly.com>
      Tested-by: default avatarDenis Ciocca <denis.ciocca@st.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06c2233a
    • Felipe Balbi's avatar
      Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid" · 4a978cfe
      Felipe Balbi authored
      commit 38317f5c0f2faae5110854f36edad810f841d62f upstream.
      
      This reverts commit ffb80fc6.
      
      Turns out that commit is wrong. Host controllers are allowed to use
      Clear Feature HALT as means to sync data toggle between host and
      periperal.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a978cfe
    • Michael Niewöhner's avatar
      usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series · 0f887c66
      Michael Niewöhner authored
      commit effd14f66cc1ef6701a19c5a56e39c35f4d395a5 upstream.
      
      Cherry G230 Stream 2.0 (G85-231) and 3.0 (G85-232) need this quirk to
      function correctly. This fixes a but where double pressing numlock locks
      up the device completely with need to replug the keyboard.
      Signed-off-by: default avatarMichael Niewöhner <linux@mniewoehner.de>
      Tested-by: default avatarMichael Niewöhner <linux@mniewoehner.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f887c66
    • Kai-Heng Feng's avatar
      USB: usb-storage: Add new IDs to ums-realtek · 72c6bc47
      Kai-Heng Feng authored
      commit a84a1bcc992f0545a51d2e120b8ca2ef20e2ea97 upstream.
      
      There are two new Realtek card readers require ums-realtek to work
      correctly.
      
      Add the new IDs to support them.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72c6bc47
    • Josef Bacik's avatar
      btrfs: release metadata before running delayed refs · 36d8dbf2
      Josef Bacik authored
      We want to release the unused reservation we have since it refills the
      delayed refs reserve, which will make everything go smoother when
      running the delayed refs if we're short on our reservation.
      
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarOmar Sandoval <osandov@fb.com>
      Reviewed-by: default avatarLiu Bo <bo.liu@linux.alibaba.com>
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      36d8dbf2
    • Richard Genoud's avatar
      dmaengine: at_hdmac: fix module unloading · 07d8abac
      Richard Genoud authored
      commit 77e75fda94d2ebb86aa9d35fb1860f6395bf95de upstream.
      
      of_dma_controller_free() was not called on module onloading.
      This lead to a soft lockup:
      watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
      Modules linked in: at_hdmac [last unloaded: at_hdmac]
      when of_dma_request_slave_channel() tried to call ofdma->of_dma_xlate().
      
      Cc: stable@vger.kernel.org
      Fixes: bbe89c8e ("at_hdmac: move to generic DMA binding")
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07d8abac
    • Richard Genoud's avatar
      dmaengine: at_hdmac: fix memory leak in at_dma_xlate() · 0daa7fc2
      Richard Genoud authored
      commit 98f5f932254b88ce828bc8e4d1642d14e5854caa upstream.
      
      The leak was found when opening/closing a serial port a great number of
      time, increasing kmalloc-32 in slabinfo.
      
      Each time the port was opened, dma_request_slave_channel() was called.
      Then, in at_dma_xlate(), atslave was allocated with devm_kzalloc() and
      never freed. (Well, it was free at module unload, but that's not what we
      want).
      So, here, kzalloc is more suited for the job since it has to be freed in
      atc_free_chan_resources().
      
      Cc: stable@vger.kernel.org
      Fixes: bbe89c8e ("at_hdmac: move to generic DMA binding")
      Reported-by: default avatarMario Forner <m.forner@be4energy.com>
      Suggested-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0daa7fc2
    • Pan Bian's avatar
      ext2: fix potential use after free · 4e443d70
      Pan Bian authored
      commit ecebf55d27a11538ea84aee0be643dd953f830d5 upstream.
      
      The function ext2_xattr_set calls brelse(bh) to drop the reference count
      of bh. After that, bh may be freed. However, following brelse(bh),
      it reads bh->b_data via macro HDR(bh). This may result in a
      use-after-free bug. This patch moves brelse(bh) after reading field.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e443d70
    • Takashi Iwai's avatar
      ALSA: sparc: Fix invalid snd_free_pages() at error path · 9c4a8f6f
      Takashi Iwai authored
      commit 9a20332ab373b1f8f947e0a9c923652b32dab031 upstream.
      
      Some spurious calls of snd_free_pages() have been overlooked and
      remain in the error paths of sparc cs4231 driver code.  Since
      runtime->dma_area is managed by the PCM core helper, we shouldn't
      release manually.
      
      Drop the superfluous calls.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c4a8f6f
    • Takashi Iwai's avatar
      ALSA: control: Fix race between adding and removing a user element · e3ff60d8
      Takashi Iwai authored
      commit e1a7bfe3807974e66f971f2589d4e0197ec0fced upstream.
      
      The procedure for adding a user control element has some window opened
      for race against the concurrent removal of a user element.  This was
      caught by syzkaller, hitting a KASAN use-after-free error.
      
      This patch addresses the bug by wrapping the whole procedure to add a
      user control element with the card->controls_rwsem, instead of only
      around the increment of card->user_ctl_count.
      
      This required a slight code refactoring, too.  The function
      snd_ctl_add() is split to two parts: a core function to add the
      control element and a part calling it.  The former is called from the
      function for adding a user control element inside the controls_rwsem.
      
      One change to be noted is that snd_ctl_notify() for adding a control
      element gets called inside the controls_rwsem as well while it was
      called outside the rwsem.  But this should be OK, as snd_ctl_notify()
      takes another (finer) rwlock instead of rwsem, and the call of
      snd_ctl_notify() inside rwsem is already done in another code path.
      
      Reported-by: syzbot+dc09047bce3820621ba2@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3ff60d8
    • Takashi Iwai's avatar
      ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write · 5d3201bb
      Takashi Iwai authored
      commit 7194eda1ba0872d917faf3b322540b4f57f11ba5 upstream.
      
      The function snd_ac97_put_spsa() gets the bit shift value from the
      associated private_value, but it extracts too much; the current code
      extracts 8 bit values in bits 8-15, but this is a combination of two
      nibbles (bits 8-11 and bits 12-15) for left and right shifts.
      Due to the incorrect bits extraction, the actual shift may go beyond
      the 32bit value, as spotted recently by UBSAN check:
       UBSAN: Undefined behaviour in sound/pci/ac97/ac97_codec.c:836:7
       shift exponent 68 is too large for 32-bit type 'int'
      
      This patch fixes the shift value extraction by masking the properly
      with 0x0f instead of 0xff.
      Reported-and-tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d3201bb
    • Takashi Iwai's avatar
      ALSA: wss: Fix invalid snd_free_pages() at error path · 12b2efff
      Takashi Iwai authored
      commit 7b69154171b407844c273ab4c10b5f0ddcd6aa29 upstream.
      
      Some spurious calls of snd_free_pages() have been overlooked and
      remain in the error paths of wss driver code.  Since runtime->dma_area
      is managed by the PCM core helper, we shouldn't release manually.
      
      Drop the superfluous calls.
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12b2efff
    • Maximilian Heyne's avatar
      fs: fix lost error code in dio_complete · 55eb06b7
      Maximilian Heyne authored
      commit 41e817bca3acd3980efe5dd7d28af0e6f4ab9247 upstream.
      
      commit e2592217 ("fs: simplify the
      generic_write_sync prototype") reworked callers of generic_write_sync(),
      and ended up dropping the error return for the directio path. Prior to
      that commit, in dio_complete(), an error would be bubbled up the stack,
      but after that commit, errors passed on to dio_complete were eaten up.
      
      This was reported on the list earlier, and a fix was proposed in
      https://lore.kernel.org/lkml/20160921141539.GA17898@infradead.org/, but
      never followed up with.  We recently hit this bug in our testing where
      fencing io errors, which were previously erroring out with EIO, were
      being returned as success operations after this commit.
      
      The fix proposed on the list earlier was a little short -- it would have
      still called generic_write_sync() in case `ret` already contained an
      error. This fix ensures generic_write_sync() is only called when there's
      no pending error in the write. Additionally, transferred is replaced
      with ret to bring this code in line with other callers.
      
      Fixes: e2592217 ("fs: simplify the generic_write_sync prototype")
      Reported-by: default avatarRavi Nankani <rnankani@amazon.com>
      Signed-off-by: default avatarMaximilian Heyne <mheyne@amazon.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      CC: Torsten Mehlan <tomeh@amazon.de>
      CC: Uwe Dannowski <uwed@amazon.de>
      CC: Amit Shah <aams@amazon.de>
      CC: David Woodhouse <dwmw@amazon.co.uk>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      55eb06b7
    • Jiri Olsa's avatar
      perf/x86/intel: Add generic branch tracing check to intel_pmu_has_bts() · 54f73829
      Jiri Olsa authored
      commit 67266c1080ad56c31af72b9c18355fde8ccc124a upstream.
      
      Currently we check the branch tracing only by checking for the
      PERF_COUNT_HW_BRANCH_INSTRUCTIONS event of PERF_TYPE_HARDWARE
      type. But we can define the same event with the PERF_TYPE_RAW
      type.
      
      Changing the intel_pmu_has_bts() code to check on event's final
      hw config value, so both HW types are covered.
      
      Adding unlikely to intel_pmu_has_bts() condition calls, because
      it was used in the original code in intel_bts_constraints.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: <stable@vger.kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/20181121101612.16272-2-jolsa@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54f73829
    • Jiri Olsa's avatar
      perf/x86/intel: Move branch tracing setup to the Intel-specific source file · 08c133e8
      Jiri Olsa authored
      commit ed6101bbf6266ee83e620b19faa7c6ad56bb41ab upstream.
      
      Moving branch tracing setup to Intel core object into separate
      intel_pmu_bts_config function, because it's Intel specific.
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: <stable@vger.kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/20181121101612.16272-1-jolsa@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08c133e8
    • Filipe Manana's avatar
      Btrfs: ensure path name is null terminated at btrfs_control_ioctl · 6e1210e2
      Filipe Manana authored
      commit f505754fd6599230371cb01b9332754ddc104be1 upstream.
      
      We were using the path name received from user space without checking that
      it is null terminated. While btrfs-progs is well behaved and does proper
      validation and null termination, someone could call the ioctl and pass
      a non-null terminated patch, leading to buffer overrun problems in the
      kernel.  The ioctl is protected by CAP_SYS_ADMIN.
      
      So just set the last byte of the path to a null character, similar to what
      we do in other ioctls (add/remove/resize device, snapshot creation, etc).
      
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarAnand Jain <anand.jain@oracle.com>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e1210e2
    • Max Filippov's avatar
      xtensa: fix coprocessor context offset definitions · f4038875
      Max Filippov authored
      commit 03bc996af0cc71c7f30c384d8ce7260172423b34 upstream.
      
      Coprocessor context offsets are used by the assembly code that moves
      coprocessor context between the individual fields of the
      thread_info::xtregs_cp structure and coprocessor registers.
      This fixes coprocessor context clobbering on flushing and reloading
      during normal user code execution and user process debugging in the
      presence of more than one coprocessor in the core configuration.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4038875
    • Max Filippov's avatar
      xtensa: enable coprocessors that are being flushed · c26e3c6c
      Max Filippov authored
      commit 2958b66694e018c552be0b60521fec27e8d12988 upstream.
      
      coprocessor_flush_all may be called from a context of a thread that is
      different from the thread being flushed. In that case contents of the
      cpenable special register may not match ti->cpenable of the target
      thread, resulting in unhandled coprocessor exception in the kernel
      context.
      Set cpenable special register to the ti->cpenable of the target register
      for the duration of the flush and restore it afterwards.
      This fixes the following crash caused by coprocessor register inspection
      in native gdb:
      
        (gdb) p/x $w0
        Illegal instruction in kernel: sig: 9 [#1] PREEMPT
        Call Trace:
          ___might_sleep+0x184/0x1a4
          __might_sleep+0x41/0xac
          exit_signals+0x14/0x218
          do_exit+0xc9/0x8b8
          die+0x99/0xa0
          do_illegal_instruction+0x18/0x6c
          common_exception+0x77/0x77
          coprocessor_flush+0x16/0x3c
          arch_ptrace+0x46c/0x674
          sys_ptrace+0x2ce/0x3b4
          system_call+0x54/0x80
          common_exception+0x77/0x77
        note: gdb[100] exited with preempt_count 1
        Killed
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c26e3c6c
    • Wanpeng Li's avatar
      KVM: X86: Fix scan ioapic use-before-initialization · 3a468e8e
      Wanpeng Li authored
      commit e97f852fd4561e77721bb9a4e0ea9d98305b1e93 upstream.
      
      Reported by syzkaller:
      
       BUG: unable to handle kernel NULL pointer dereference at 00000000000001c8
       PGD 80000003ec4da067 P4D 80000003ec4da067 PUD 3f7bfa067 PMD 0
       Oops: 0000 [#1] PREEMPT SMP PTI
       CPU: 7 PID: 5059 Comm: debug Tainted: G           OE     4.19.0-rc5 #16
       RIP: 0010:__lock_acquire+0x1a6/0x1990
       Call Trace:
        lock_acquire+0xdb/0x210
        _raw_spin_lock+0x38/0x70
        kvm_ioapic_scan_entry+0x3e/0x110 [kvm]
        vcpu_enter_guest+0x167e/0x1910 [kvm]
        kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
        kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
        do_vfs_ioctl+0xa5/0x690
        ksys_ioctl+0x6d/0x80
        __x64_sys_ioctl+0x1a/0x20
        do_syscall_64+0x83/0x6e0
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT6 msr
      and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
      However, irqchip is not initialized by this simple testcase, ioapic/apic
      objects should not be accessed.
      This can be triggered by the following program:
      
          #define _GNU_SOURCE
      
          #include <endian.h>
          #include <stdint.h>
          #include <stdio.h>
          #include <stdlib.h>
          #include <string.h>
          #include <sys/syscall.h>
          #include <sys/types.h>
          #include <unistd.h>
      
          uint64_t r[3] = {0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff};
      
          int main(void)
          {
          	syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
          	long res = 0;
          	memcpy((void*)0x20000040, "/dev/kvm", 9);
          	res = syscall(__NR_openat, 0xffffffffffffff9c, 0x20000040, 0, 0);
          	if (res != -1)
          		r[0] = res;
          	res = syscall(__NR_ioctl, r[0], 0xae01, 0);
          	if (res != -1)
          		r[1] = res;
          	res = syscall(__NR_ioctl, r[1], 0xae41, 0);
          	if (res != -1)
          		r[2] = res;
          	memcpy(
          			(void*)0x20000080,
          			"\x01\x00\x00\x00\x00\x5b\x61\xbb\x96\x00\x00\x40\x00\x00\x00\x00\x01\x00"
          			"\x08\x00\x00\x00\x00\x00\x0b\x77\xd1\x78\x4d\xd8\x3a\xed\xb1\x5c\x2e\x43"
          			"\xaa\x43\x39\xd6\xff\xf5\xf0\xa8\x98\xf2\x3e\x37\x29\x89\xde\x88\xc6\x33"
          			"\xfc\x2a\xdb\xb7\xe1\x4c\xac\x28\x61\x7b\x9c\xa9\xbc\x0d\xa0\x63\xfe\xfe"
          			"\xe8\x75\xde\xdd\x19\x38\xdc\x34\xf5\xec\x05\xfd\xeb\x5d\xed\x2e\xaf\x22"
          			"\xfa\xab\xb7\xe4\x42\x67\xd0\xaf\x06\x1c\x6a\x35\x67\x10\x55\xcb",
          			106);
          	syscall(__NR_ioctl, r[2], 0x4008ae89, 0x20000080);
          	syscall(__NR_ioctl, r[2], 0xae80, 0);
          	return 0;
          }
      
      This patch fixes it by bailing out scan ioapic if ioapic is not initialized in
      kernel.
      Reported-by: default avatarWei Wu <ww9210@gmail.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Wei Wu <ww9210@gmail.com>
      Signed-off-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a468e8e
    • Jim Mattson's avatar
      kvm: svm: Ensure an IBPB on all affected CPUs when freeing a vmcb · 43dd9f48
      Jim Mattson authored
      commit fd65d3142f734bc4376053c8d75670041903134d upstream.
      
      Previously, we only called indirect_branch_prediction_barrier on the
      logical CPU that freed a vmcb. This function should be called on all
      logical CPUs that last loaded the vmcb in question.
      
      Fixes: 15d45071 ("KVM/x86: Add IBPB support")
      Reported-by: default avatarNeel Natu <neelnatu@google.com>
      Signed-off-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43dd9f48
    • Junaid Shahid's avatar
      kvm: mmu: Fix race in emulated page table writes · aa716434
      Junaid Shahid authored
      commit 0e0fee5c539b61fdd098332e0e2cc375d9073706 upstream.
      
      When a guest page table is updated via an emulated write,
      kvm_mmu_pte_write() is called to update the shadow PTE using the just
      written guest PTE value. But if two emulated guest PTE writes happened
      concurrently, it is possible that the guest PTE and the shadow PTE end
      up being out of sync. Emulated writes do not mark the shadow page as
      unsync-ed, so this inconsistency will not be resolved even by a guest TLB
      flush (unless the page was marked as unsync-ed at some other point).
      
      This is fixed by re-reading the current value of the guest PTE after the
      MMU lock has been acquired instead of just using the value that was
      written prior to calling kvm_mmu_pte_write().
      Signed-off-by: default avatarJunaid Shahid <junaids@google.com>
      Reviewed-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa716434
    • Bernd Eckstein's avatar
      usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2 · ff67a7d3
      Bernd Eckstein authored
      [ Upstream commit 45611c61dd503454b2edae00aabe1e429ec49ebe ]
      
      The bug is not easily reproducable, as it may occur very infrequently
      (we had machines with 20minutes heavy downloading before it occurred)
      However, on a virual machine (VMWare on Windows 10 host) it occurred
      pretty frequently (1-2 seconds after a speedtest was started)
      
      dev->tx_skb mab be freed via dev_kfree_skb_irq on a callback
      before it is set.
      
      This causes the following problems:
      - double free of the skb or potential memory leak
      - in dmesg: 'recvmsg bug' and 'recvmsg bug 2' and eventually
        general protection fault
      
      Example dmesg output:
      [  134.841986] ------------[ cut here ]------------
      [  134.841987] recvmsg bug: copied 9C24A555 seq 9C24B557 rcvnxt 9C25A6B3 fl 0
      [  134.841993] WARNING: CPU: 7 PID: 2629 at /build/linux-hwe-On9fm7/linux-hwe-4.15.0/net/ipv4/tcp.c:1865 tcp_recvmsg+0x44d/0xab0
      [  134.841994] Modules linked in: ipheth(OE) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd vmw_balloon intel_rapl_perf joydev input_leds serio_raw vmw_vsock_vmci_transport vsock shpchp i2c_piix4 mac_hid binfmt_misc vmw_vmci parport_pc ppdev lp parport autofs4 vmw_pvscsi vmxnet3 hid_generic usbhid hid vmwgfx ttm drm_kms_helper syscopyarea sysfillrect mptspi mptscsih sysimgblt ahci psmouse fb_sys_fops pata_acpi mptbase libahci e1000 drm scsi_transport_spi
      [  134.842046] CPU: 7 PID: 2629 Comm: python Tainted: G        W  OE    4.15.0-34-generic #37~16.04.1-Ubuntu
      [  134.842046] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
      [  134.842048] RIP: 0010:tcp_recvmsg+0x44d/0xab0
      [  134.842048] RSP: 0018:ffffa6630422bcc8 EFLAGS: 00010286
      [  134.842049] RAX: 0000000000000000 RBX: ffff997616f4f200 RCX: 0000000000000006
      [  134.842049] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff9976257d6490
      [  134.842050] RBP: ffffa6630422bd98 R08: 0000000000000001 R09: 000000000004bba4
      [  134.842050] R10: 0000000001e00c6f R11: 000000000004bba4 R12: ffff99760dee3000
      [  134.842051] R13: 0000000000000000 R14: ffff99760dee3514 R15: 0000000000000000
      [  134.842051] FS:  00007fe332347700(0000) GS:ffff9976257c0000(0000) knlGS:0000000000000000
      [  134.842052] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  134.842053] CR2: 0000000001e41000 CR3: 000000020e9b4006 CR4: 00000000003606e0
      [  134.842055] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  134.842055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  134.842057] Call Trace:
      [  134.842060]  ? aa_sk_perm+0x53/0x1a0
      [  134.842064]  inet_recvmsg+0x51/0xc0
      [  134.842066]  sock_recvmsg+0x43/0x50
      [  134.842070]  SYSC_recvfrom+0xe4/0x160
      [  134.842072]  ? __schedule+0x3de/0x8b0
      [  134.842075]  ? ktime_get_ts64+0x4c/0xf0
      [  134.842079]  SyS_recvfrom+0xe/0x10
      [  134.842082]  do_syscall_64+0x73/0x130
      [  134.842086]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      [  134.842086] RIP: 0033:0x7fe331f5a81d
      [  134.842088] RSP: 002b:00007ffe8da98398 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
      [  134.842090] RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 00007fe331f5a81d
      [  134.842094] RDX: 00000000000003fb RSI: 0000000001e00874 RDI: 0000000000000003
      [  134.842095] RBP: 00007fe32f642c70 R08: 0000000000000000 R09: 0000000000000000
      [  134.842097] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe332347698
      [  134.842099] R13: 0000000001b7e0a0 R14: 0000000001e00874 R15: 0000000000000000
      [  134.842103] Code: 24 fd ff ff e9 cc fe ff ff 48 89 d8 41 8b 8c 24 10 05 00 00 44 8b 45 80 48 c7 c7 08 bd 59 8b 48 89 85 68 ff ff ff e8 b3 c4 7d ff <0f> 0b 48 8b 85 68 ff ff ff e9 e9 fe ff ff 41 8b 8c 24 10 05 00
      [  134.842126] ---[ end trace b7138fc08c83147f ]---
      [  134.842144] general protection fault: 0000 [#1] SMP PTI
      [  134.842145] Modules linked in: ipheth(OE) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd vmw_balloon intel_rapl_perf joydev input_leds serio_raw vmw_vsock_vmci_transport vsock shpchp i2c_piix4 mac_hid binfmt_misc vmw_vmci parport_pc ppdev lp parport autofs4 vmw_pvscsi vmxnet3 hid_generic usbhid hid vmwgfx ttm drm_kms_helper syscopyarea sysfillrect mptspi mptscsih sysimgblt ahci psmouse fb_sys_fops pata_acpi mptbase libahci e1000 drm scsi_transport_spi
      [  134.842161] CPU: 7 PID: 2629 Comm: python Tainted: G        W  OE    4.15.0-34-generic #37~16.04.1-Ubuntu
      [  134.842162] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
      [  134.842164] RIP: 0010:tcp_close+0x2c6/0x440
      [  134.842165] RSP: 0018:ffffa6630422bde8 EFLAGS: 00010202
      [  134.842167] RAX: 0000000000000000 RBX: ffff99760dee3000 RCX: 0000000180400034
      [  134.842168] RDX: 5c4afd407207a6c4 RSI: ffffe868495bd300 RDI: ffff997616f4f200
      [  134.842169] RBP: ffffa6630422be08 R08: 0000000016f4d401 R09: 0000000180400034
      [  134.842169] R10: ffffa6630422bd98 R11: 0000000000000000 R12: 000000000000600c
      [  134.842170] R13: 0000000000000000 R14: ffff99760dee30c8 R15: ffff9975bd44fe00
      [  134.842171] FS:  00007fe332347700(0000) GS:ffff9976257c0000(0000) knlGS:0000000000000000
      [  134.842173] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  134.842174] CR2: 0000000001e41000 CR3: 000000020e9b4006 CR4: 00000000003606e0
      [  134.842177] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  134.842178] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  134.842179] Call Trace:
      [  134.842181]  inet_release+0x42/0x70
      [  134.842183]  __sock_release+0x42/0xb0
      [  134.842184]  sock_close+0x15/0x20
      [  134.842187]  __fput+0xea/0x220
      [  134.842189]  ____fput+0xe/0x10
      [  134.842191]  task_work_run+0x8a/0xb0
      [  134.842193]  exit_to_usermode_loop+0xc4/0xd0
      [  134.842195]  do_syscall_64+0xf4/0x130
      [  134.842197]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      [  134.842197] RIP: 0033:0x7fe331f5a560
      [  134.842198] RSP: 002b:00007ffe8da982e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
      [  134.842200] RAX: 0000000000000000 RBX: 00007fe32f642c70 RCX: 00007fe331f5a560
      [  134.842201] RDX: 00000000008f5320 RSI: 0000000001cd4b50 RDI: 0000000000000003
      [  134.842202] RBP: 00007fe32f6500f8 R08: 000000000000003c R09: 00000000009343c0
      [  134.842203] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe32f6500d0
      [  134.842204] R13: 00000000008f5320 R14: 00000000008f5320 R15: 0000000001cd4770
      [  134.842205] Code: c8 00 00 00 45 31 e4 49 39 fe 75 4d eb 50 83 ab d8 00 00 00 01 48 8b 17 48 8b 47 08 48 c7 07 00 00 00 00 48 c7 47 08 00 00 00 00 <48> 89 42 08 48 89 10 0f b6 57 34 8b 47 2c 2b 47 28 83 e2 01 80
      [  134.842226] RIP: tcp_close+0x2c6/0x440 RSP: ffffa6630422bde8
      [  134.842227] ---[ end trace b7138fc08c831480 ]---
      
      The proposed patch eliminates a potential racing condition.
      Before, usb_submit_urb was called and _after_ that, the skb was attached
      (dev->tx_skb). So, on a callback it was possible, however unlikely that the
      skb was freed before it was set. That way (because dev->tx_skb was not set
      to NULL after it was freed), it could happen that a skb from a earlier
      transmission was freed a second time (and the skb we should have freed did
      not get freed at all)
      
      Now we free the skb directly in ipheth_tx(). It is not passed to the
      callback anymore, eliminating the posibility of a double free of the same
      skb. Depending on the retval of usb_submit_urb() we use dev_kfree_skb_any()
      respectively dev_consume_skb_any() to free the skb.
      Signed-off-by: default avatarOliver Zweigle <Oliver.Zweigle@faro.com>
      Signed-off-by: default avatarBernd Eckstein <3ernd.Eckstein@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff67a7d3
    • Julian Wiedmann's avatar
      s390/qeth: fix length check in SNMP processing · 1d3891c7
      Julian Wiedmann authored
      [ Upstream commit 9a764c1e59684c0358e16ccaafd870629f2cfe67 ]
      
      The response for a SNMP request can consist of multiple parts, which
      the cmd callback stages into a kernel buffer until all parts have been
      received. If the callback detects that the staging buffer provides
      insufficient space, it bails out with error.
      This processing is buggy for the first part of the response - while it
      initially checks for a length of 'data_len', it later copies an
      additional amount of 'offsetof(struct qeth_snmp_cmd, data)' bytes.
      
      Fix the calculation of 'data_len' for the first part of the response.
      This also nicely cleans up the memcpy code.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d3891c7
    • Pan Bian's avatar
      rapidio/rionet: do not free skb before reading its length · 13a3d890
      Pan Bian authored
      [ Upstream commit cfc435198f53a6fa1f656d98466b24967ff457d0 ]
      
      skb is freed via dev_kfree_skb_any, however, skb->len is read then. This
      may result in a use-after-free bug.
      
      Fixes: e6161d64 ("rapidio/rionet: rework driver initialization and removal")
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13a3d890
    • Petr Machata's avatar
      net: skb_scrub_packet(): Scrub offload_fwd_mark · d39ebd19
      Petr Machata authored
      [ Upstream commit b5dd186d10ba59e6b5ba60e42b3b083df56df6f3 ]
      
      When a packet is trapped and the corresponding SKB marked as
      already-forwarded, it retains this marking even after it is forwarded
      across veth links into another bridge. There, since it ingresses the
      bridge over veth, which doesn't have offload_fwd_mark, it triggers a
      warning in nbp_switchdev_frame_mark().
      
      Then nbp_switchdev_allowed_egress() decides not to allow egress from
      this bridge through another veth, because the SKB is already marked, and
      the mark (of 0) of course matches. Thus the packet is incorrectly
      blocked.
      
      Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That
      function is called from tunnels and also from veth, and thus catches the
      cases where traffic is forwarded between bridges and transformed in a
      way that invalidates the marking.
      
      Fixes: 6bc506b4 ("bridge: switchdev: Add forward mark support for stacked devices")
      Fixes: abf4bb6b ("skbuff: Add the offload_mr_fwd_mark field")
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Suggested-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d39ebd19