1. 17 Dec, 2018 33 commits
  2. 13 Dec, 2018 7 commits
    • Vasyl Vavrychuk's avatar
      mac80211_hwsim: Timer should be initialized before device registered · 199a81ac
      Vasyl Vavrychuk authored
      commit a1881c9b
      
       upstream.
      
      Otherwise if network manager starts configuring Wi-Fi interface
      immidiatelly after getting notification of its creation, we will get
      NULL pointer dereference:
      
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: [<ffffffff95ae94c8>] hrtimer_active+0x28/0x50
        ...
        Call Trace:
         [<ffffffff95ae9997>] ? hrtimer_try_to_cancel+0x27/0x110
         [<ffffffff95ae9a95>] ? hrtimer_cancel+0x15/0x20
         [<ffffffffc0803bf0>] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim]
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVasyl Vavrychuk <vasyl.vavrychuk@globallogic.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      199a81ac
    • Dan Williams's avatar
      libnvdimm, pfn: Pad pfn namespaces relative to other regions · 4794d94b
      Dan Williams authored
      commit ae86cbfe upstream.
      
      Commit cfe30b87 "libnvdimm, pmem: adjust for section collisions with
      'System RAM'" enabled Linux to workaround occasions where platform
      firmware arranges for "System RAM" and "Persistent Memory" to collide
      within a single section boundary. Unfortunately, as reported in this
      issue [1], platform firmware can inflict the same collision between
      persistent memory regions.
      
      The approach of interrogating iomem_resource does not work in this
      case because platform firmware may merge multiple regions into a single
      iomem_resource range. Instead provide a method to interrogate regions
      that share the same parent bus.
      
      This is a stop-gap until the core-MM can grow support for hotplug on
      sub-section boundaries.
      
      [1]: https://github.com/pmem/ndctl/issues/76
      
      Fixes: cfe30b87
      
       ("libnvdimm, pmem: adjust for section collisions with...")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarPatrick Geary <patrickg@supermicro.com>
      Tested-by: default avatarPatrick Geary <patrickg@supermicro.com>
      Reviewed-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4794d94b
    • Macpaul Lin's avatar
      kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var() · b919b484
      Macpaul Lin authored
      commit dada6a43
      
       upstream.
      
      This patch is trying to fix KE issue due to
      "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198"
      reported by Syzkaller scan."
      
      [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198
      [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0
      [26364:syz-executor0]Call trace:
      [26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470
      [26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30
      [26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128
      [26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8
      [26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390
      [26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20
      [26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198
      [26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270
      [26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90
      [26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158
      [26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8
      [26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0
      [26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0
      [26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8
      [26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208
      [26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:report&]The buggy address belongs to the variable:
      [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:report&]Memory state around the buggy address:
      [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa
      [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
      [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
      [26364:syz-executor0][name:report&]                                       ^
      [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
      [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa
      [26364:syz-executor0][name:report&]
      [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint
      [26364:syz-executor0]------------[cut here]------------
      
      After checking the source code, we've found there might be an out-of-bounds
      access to "config[len - 1]" array when the variable "len" is zero.
      Signed-off-by: default avatarMacpaul Lin <macpaul@gmail.com>
      Acked-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b919b484
    • Chanho Park's avatar
      tty: do not set TTY_IO_ERROR flag if console port · e4c3cc6b
      Chanho Park authored
      commit 2a486026 upstream.
      
      Since Commit 761ed4a9 ('tty: serial_core: convert uart_close to use
      tty_port_close') and Commit 4dda864d ('tty: serial_core: Fix serial
      console crash on port shutdown), a serial port which is used as
      console can be stuck when logging out if there is a remained process.
      After logged out, agetty will try to grab the serial port but it will
      be failed because the previous process did not release the port
      correctly. To fix this, TTY_IO_ERROR bit should not be enabled of
      tty_port_close if the port is console port.
      
      Reproduce step:
      - Run background processes from serial console
      $ while true; do sleep 10; done &
      
      - Log out
      $ logout
      -> Stuck
      
      - Read journal log by journalctl | tail
      Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0.
      Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0.
      Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty
      
      Fixes: 761ed4a9
      
       ("tty: serial_core: convert uart_close to use tty_port_close")
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Signed-off-by: default avatarChanho Park <parkch98@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4c3cc6b
    • Peter Shih's avatar
      tty: serial: 8250_mtk: always resume the device in probe. · 4f50d3a0
      Peter Shih authored
      commit 100bc3e2 upstream.
      
      serial8250_register_8250_port calls uart_config_port, which calls
      config_port on the port before it tries to power on the port. So we need
      the port to be on before calling serial8250_register_8250_port. Change
      the code to always do a runtime resume in probe before registering port,
      and always do a runtime suspend in remove.
      
      This basically reverts the change in commit 68e5fc4a ("tty: serial:
      8250_mtk: use pm_runtime callbacks for enabling"), but still use
      pm_runtime callbacks.
      
      Fixes: 68e5fc4a
      
       ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling")
      Signed-off-by: default avatarPeter Shih <pihsun@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f50d3a0
    • Dexuan Cui's avatar
      Drivers: hv: vmbus: Offload the handling of channels to two workqueues · c1063941
      Dexuan Cui authored
      commit 37c2578c upstream.
      
      vmbus_process_offer() mustn't call channel->sc_creation_callback()
      directly for sub-channels, because sc_creation_callback() ->
      vmbus_open() may never get the host's response to the
      OPEN_CHANNEL message (the host may rescind a channel at any time,
      e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
      may not wake up the vmbus_open() as it's blocked due to a non-zero
      vmbus_connection.offer_in_progress, and finally we have a deadlock.
      
      The above is also true for primary channels, if the related device
      drivers use sync probing mode by default.
      
      And, usually the handling of primary channels and sub-channels can
      depend on each other, so we should offload them to different
      workqueues to avoid possible deadlock, e.g. in sync-probing mode,
      NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
      rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
      and waits for all the sub-channels to appear, but the latter
      can't get the rtnl_lock and this blocks the handling of sub-channels.
      
      The patch can fix the multiple-NIC deadlock described above for
      v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
      of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
      but don't enable async-probing for Hyper-V drivers (yet).
      
      The patch can also fix the hang issue in sub-channel's handling described
      above for all versions of kernels, including v4.19 and v4.20-rc4.
      
      So actually the patch should be applied to all the existing kernels,
      not only the kernels that have 8195b139.
      
      Fixes: 8195b139
      
       ("hv_netvsc: fix deadlock on hotplug")
      Cc: stable@vger.kernel.org
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      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>
      c1063941
    • Alex Deucher's avatar
      drm/amdgpu/gmc8: update MC firmware for polaris · eff5e74f
      Alex Deucher authored
      commit a81a7c9c
      
       upstream.
      
      Some variants require different MC firmware images.
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarJunwei Zhang <Jerry.Zhang@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eff5e74f