1. 01 12月, 2019 40 次提交
    • M
      powerpc/book3s64: Fix link stack flush on context switch · 0a60d4bd
      Michael Ellerman 提交于
      commit 39e72bf96f5847ba87cc5bd7a3ce0fed813dc9ad upstream.
      
      In commit ee13cb24 ("powerpc/64s: Add support for software count
      cache flush"), I added support for software to flush the count
      cache (indirect branch cache) on context switch if firmware told us
      that was the required mitigation for Spectre v2.
      
      As part of that code we also added a software flush of the link
      stack (return address stack), which protects against Spectre-RSB
      between user processes.
      
      That is all correct for CPUs that activate that mitigation, which is
      currently Power9 Nimbus DD2.3.
      
      What I got wrong is that on older CPUs, where firmware has disabled
      the count cache, we also need to flush the link stack on context
      switch.
      
      To fix it we create a new feature bit which is not set by firmware,
      which tells us we need to flush the link stack. We set that when
      firmware tells us that either of the existing Spectre v2 mitigations
      are enabled.
      
      Then we adjust the patching code so that if we see that feature bit we
      enable the link stack flush. If we're also told to flush the count
      cache in software then we fall through and do that also.
      
      On the older CPUs we don't need to do do the software count cache
      flush, firmware has disabled it, so in that case we patch in an early
      return after the link stack flush.
      
      The naming of some of the functions is awkward after this patch,
      because they're called "count cache" but they also do link stack. But
      we'll fix that up in a later commit to ease backporting.
      
      This is the fix for CVE-2019-18660.
      Reported-by: NAnthony Steinhauser <asteinhauser@google.com>
      Fixes: ee13cb24 ("powerpc/64s: Add support for software count cache flush")
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a60d4bd
    • C
      powerpc/64s: support nospectre_v2 cmdline option · 19d98b4d
      Christopher M. Riedl 提交于
      commit d8f0e0b073e1ec52a05f0c2a56318b47387d2f10 upstream.
      
      Add support for disabling the kernel implemented spectre v2 mitigation
      (count cache flush on context switch) via the nospectre_v2 and
      mitigations=off cmdline options.
      Suggested-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NChristopher M. Riedl <cmr@informatik.wtf>
      Reviewed-by: NAndrew Donnellan <ajd@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190524024647.381-1-cmr@informatik.wtfSigned-off-by: NDaniel Axtens <dja@axtens.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19d98b4d
    • B
      staging: comedi: usbduxfast: usbduxfast_ai_cmdtest rounding error · b7e2a040
      Bernd Porr 提交于
      commit 5618332e5b955b4bff06d0b88146b971c8dd7b32 upstream.
      
      The userspace comedilib function 'get_cmd_generic_timed' fills
      the cmd structure with an informed guess and then calls the
      function 'usbduxfast_ai_cmdtest' in this driver repeatedly while
      'usbduxfast_ai_cmdtest' is modifying the cmd struct until it
      no longer changes. However, because of rounding errors this never
      converged because 'steps = (cmd->convert_arg * 30) / 1000' and then
      back to 'cmd->convert_arg = (steps * 1000) / 30' won't be the same
      because of rounding errors. 'Steps' should only be converted back to
      the 'convert_arg' if 'steps' has actually been modified. In addition
      the case of steps being 0 wasn't checked which is also now done.
      Signed-off-by: NBernd Porr <mail@berndporr.me.uk>
      Cc: <stable@vger.kernel.org> # 4.4+
      Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
      Link: https://lore.kernel.org/r/20191118230759.1727-1-mail@berndporr.me.ukSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7e2a040
    • A
      USB: serial: option: add support for Foxconn T77W968 LTE modules · 4101916e
      Aleksander Morgado 提交于
      commit f0797095423e6ea3b4be61134ee353c7f504d440 upstream.
      
      These are the Foxconn-branded variants of the Dell DW5821e modules,
      same USB layout as those. The device exposes AT, NMEA and DIAG ports
      in both USB configurations.
      
      P:  Vendor=0489 ProdID=e0b4 Rev=03.18
      S:  Manufacturer=FII
      S:  Product=T77W968 LTE
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      
      P:  Vendor=0489 ProdID=e0b4 Rev=03.18
      S:  Manufacturer=FII
      S:  Product=T77W968 LTE
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#=0x6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      Signed-off-by: NAleksander Morgado <aleksander@aleksander.es>
      [ johan: drop id defines ]
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4101916e
    • A
      USB: serial: option: add support for DW5821e with eSIM support · 62aca664
      Aleksander Morgado 提交于
      commit 957c31ea082e3fe5196f46d5b04018b10de47400 upstream.
      
      The device exposes AT, NMEA and DIAG ports in both USB configurations.
      Exactly same layout as the default DW5821e module, just a different
      vid/pid.
      
      P:  Vendor=413c ProdID=81e0 Rev=03.18
      S:  Manufacturer=Dell Inc.
      S:  Product=DW5821e-eSIM Snapdragon X20 LTE
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      
      P:  Vendor=413c ProdID=81e0 Rev=03.18
      S:  Manufacturer=Dell Inc.
      S:  Product=DW5821e-eSIM Snapdragon X20 LTE
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA
      I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#=0x6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      Signed-off-by: NAleksander Morgado <aleksander@aleksander.es>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62aca664
    • J
      USB: serial: mos7840: fix remote wakeup · 3349ed26
      Johan Hovold 提交于
      commit 92fe35fb9c70a00d8fbbf5bd6172c921dd9c7815 upstream.
      
      The driver was setting the device remote-wakeup feature during probe in
      violation of the USB specification (which says it should only be set
      just prior to suspending the device). This could potentially waste
      power during suspend as well as lead to spurious wakeups.
      
      Note that USB core would clear the remote-wakeup feature at first
      resume.
      
      Fixes: 3f542974 ("USB: Moschip 7840 USB-Serial Driver")
      Cc: stable <stable@vger.kernel.org>     # 2.6.19
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3349ed26
    • J
      USB: serial: mos7720: fix remote wakeup · abbda35d
      Johan Hovold 提交于
      commit ea422312a462696093b5db59d294439796cba4ad upstream.
      
      The driver was setting the device remote-wakeup feature during probe in
      violation of the USB specification (which says it should only be set
      just prior to suspending the device). This could potentially waste
      power during suspend as well as lead to spurious wakeups.
      
      Note that USB core would clear the remote-wakeup feature at first
      resume.
      
      Fixes: 0f64478c ("USB: add USB serial mos7720 driver")
      Cc: stable <stable@vger.kernel.org>     # 2.6.19
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      abbda35d
    • P
      USB: serial: mos7840: add USB ID to support Moxa UPort 2210 · 84743898
      Pavel Löbl 提交于
      commit e696d00e65e81d46e911f24b12e441037bf11b38 upstream.
      
      Add USB ID for MOXA UPort 2210. This device contains mos7820 but
      it passes GPIO0 check implemented by driver and it's detected as
      mos7840. Hence product id check is added to force mos7820 mode.
      Signed-off-by: NPavel Löbl <pavel@loebl.cz>
      Cc: stable <stable@vger.kernel.org>
      [ johan: rename id defines and add vendor-id check ]
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84743898
    • O
      appledisplay: fix error handling in the scheduled work · 356440a7
      Oliver Neukum 提交于
      commit 91feb01596e5efc0cc922cc73f5583114dccf4d2 upstream.
      
      The work item can operate on
      
      1. stale memory left over from the last transfer
      the actual length of the data transfered needs to be checked
      2. memory already freed
      the error handling in appledisplay_probe() needs
      to cancel the work in that case
      
      Reported-and-tested-by: syzbot+495dab1f175edc9c2f13@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191106124902.7765-1-oneukum@suse.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      356440a7
    • O
      USB: chaoskey: fix error case of a timeout · 0439d6b9
      Oliver Neukum 提交于
      commit 92aa5986f4f7b5a8bf282ca0f50967f4326559f5 upstream.
      
      In case of a timeout or if a signal aborts a read
      communication with the device needs to be ended
      lest we overwrite an active URB the next time we
      do IO to the device, as the URB may still be active.
      Signed-off-by: NOliver Neukum <oneukum@suse.de>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191107142856.16774-1-oneukum@suse.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0439d6b9
    • G
      usb-serial: cp201x: support Mark-10 digital force gauge · a18675e5
      Greg Kroah-Hartman 提交于
      commit 347bc8cb26388791c5881a3775cb14a3f765a674 upstream.
      
      Add support for the Mark-10 digital force gauge device to the cp201x
      driver.
      
      Based on a report and a larger patch from Joel Jennings
      Reported-by: NJoel Jennings <joel.jennings@makeitlabs.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191118092119.GA153852@kroah.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a18675e5
    • S
      usbip: Fix uninitialized symbol 'nents' in stub_recv_cmd_submit() · 61f6a3fa
      Suwan Kim 提交于
      commit 2a9125317b247f2cf35c196f968906dcf062ae2d upstream.
      
      Smatch reported that nents is not initialized and used in
      stub_recv_cmd_submit(). nents is currently initialized by sgl_alloc()
      and used to allocate multiple URBs when host controller doesn't
      support scatter-gather DMA. The use of uninitialized nents means that
      buf_len is zero and use_sg is true. But buffer length should not be
      zero when an URB uses scatter-gather DMA.
      
      To prevent this situation, add the conditional that checks buf_len
      and use_sg. And move the use of nents right after the sgl_alloc() to
      avoid the use of uninitialized nents.
      
      If the error occurs, it adds SDEV_EVENT_ERROR_MALLOC and stub_priv
      will be released by stub event handler and connection will be shut
      down.
      
      Fixes: ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NSuwan Kim <suwan.kim027@gmail.com>
      Acked-by: NShuah Khan <skhan@linuxfoundation.org>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191111141035.27788-1-suwan.kim027@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61f6a3fa
    • H
      usbip: tools: fix fd leakage in the function of read_attr_usbip_status · 375b26a8
      Hewenliang 提交于
      commit 26a4d4c00f85cb844dd11dd35e848b079c2f5e8f upstream.
      
      We should close the fd before the return of read_attr_usbip_status.
      
      Fixes: 3391ba0e ("usbip: tools: Extract generic code to be shared with vudc backend")
      Signed-off-by: NHewenliang <hewenliang4@huawei.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191025043515.20053-1-hewenliang4@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      375b26a8
    • O
      USBIP: add config dependency for SGL_ALLOC · e70448b9
      Oliver Neukum 提交于
      commit 1ec13abac58b6f24e32f0d3081ef4e7456e62ed8 upstream.
      
      USBIP uses lib/scatterlist.h
      Hence it needs to set CONFIG_SGL_ALLOC
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NShuah Khan <skhan@linuxfoundation.org>
      Link: https://lore.kernel.org/r/20191112154939.21217-1-oneukum@suse.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e70448b9
    • H
      virtio_ring: fix return code on DMA mapping fails · 5d0b56f6
      Halil Pasic 提交于
      [ Upstream commit f7728002c1c7bfa787b276a31c3ef458739b8e7c ]
      
      Commit 780bc790 ("virtio_ring: Support DMA APIs")  makes
      virtqueue_add() return -EIO when we fail to map our I/O buffers. This is
      a very realistic scenario for guests with encrypted memory, as swiotlb
      may run out of space, depending on it's size and the I/O load.
      
      The virtio-blk driver interprets -EIO form virtqueue_add() as an IO
      error, despite the fact that swiotlb full is in absence of bugs a
      recoverable condition.
      
      Let us change the return code to -ENOMEM, and make the block layer
      recover form these failures when virtio-blk encounters the condition
      described above.
      
      Cc: stable@vger.kernel.org
      Fixes: 780bc790 ("virtio_ring: Support DMA APIs")
      Signed-off-by: NHalil Pasic <pasic@linux.ibm.com>
      Tested-by: NMichael Mueller <mimu@linux.ibm.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5d0b56f6
    • S
      media: imon: invalid dereference in imon_touch_event · 78260a29
      Sean Young 提交于
      commit f3f5ba42c58d56d50f539854d8cc188944e96087 upstream.
      
      The touch timer is set up in intf1. If the second interface does not exist,
      the timer and touch input device are not setup and we get the following
      error, when touch events are reported via intf0.
      
      kernel BUG at kernel/time/timer.c:956!
      invalid opcode: 0000 [#1] SMP KASAN
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc1+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__mod_timer kernel/time/timer.c:956 [inline]
      RIP: 0010:__mod_timer kernel/time/timer.c:949 [inline]
      RIP: 0010:mod_timer+0x5a2/0xb50 kernel/time/timer.c:1100
      Code: 45 10 c7 44 24 14 ff ff ff ff 48 89 44 24 08 48 8d 45 20 48 c7 44 24 18 00 00 00 00 48 89 04 24 e9 5a fc ff ff e8 ae ce 0e 00 <0f> 0b e8 a7 ce 0e 00 4c 89 74 24 20 e9 37 fe ff ff e8 98 ce 0e 00
      RSP: 0018:ffff8881db209930 EFLAGS: 00010006
      RAX: ffffffff86c2b200 RBX: 00000000ffffa688 RCX: ffffffff83efc583
      RDX: 0000000000000100 RSI: ffffffff812f4d82 RDI: ffff8881d2356200
      RBP: ffff8881d23561e8 R08: ffffffff86c2b200 R09: ffffed103a46abeb
      R10: ffffed103a46abea R11: ffff8881d2355f53 R12: dffffc0000000000
      R13: 1ffff1103b64132d R14: ffff8881d2355f50 R15: 0000000000000006
      FS:  0000000000000000(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f75e2799000 CR3: 00000001d3b07000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <IRQ>
       imon_touch_event drivers/media/rc/imon.c:1348 [inline]
       imon_incoming_packet.isra.0+0x2546/0x2f10 drivers/media/rc/imon.c:1603
       usb_rx_callback_intf0+0x151/0x1e0 drivers/media/rc/imon.c:1734
       __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1654
       usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1719
       dummy_timer+0x120f/0x2fa2 drivers/usb/gadget/udc/dummy_hcd.c:1965
       call_timer_fn+0x179/0x650 kernel/time/timer.c:1404
       expire_timers kernel/time/timer.c:1449 [inline]
       __run_timers kernel/time/timer.c:1773 [inline]
       __run_timers kernel/time/timer.c:1740 [inline]
       run_timer_softirq+0x5e3/0x1490 kernel/time/timer.c:1786
       __do_softirq+0x221/0x912 kernel/softirq.c:292
       invoke_softirq kernel/softirq.c:373 [inline]
       irq_exit+0x178/0x1a0 kernel/softirq.c:413
       exiting_irq arch/x86/include/asm/apic.h:536 [inline]
       smp_apic_timer_interrupt+0x12f/0x500 arch/x86/kernel/apic/apic.c:1137
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
       </IRQ>
      RIP: 0010:default_idle+0x28/0x2e0 arch/x86/kernel/process.c:581
      Code: 90 90 41 56 41 55 65 44 8b 2d 44 3a 8f 7a 41 54 55 53 0f 1f 44 00 00 e8 36 ee d0 fb e9 07 00 00 00 0f 00 2d fa dd 4f 00 fb f4 <65> 44 8b 2d 20 3a 8f 7a 0f 1f 44 00 00 5b 5d 41 5c 41 5d 41 5e c3
      RSP: 0018:ffffffff86c07da8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
      RAX: 0000000000000007 RBX: ffffffff86c2b200 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffffff86c2ba4c
      RBP: fffffbfff0d85640 R08: ffffffff86c2b200 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
       cpuidle_idle_call kernel/sched/idle.c:154 [inline]
       do_idle+0x3b6/0x500 kernel/sched/idle.c:263
       cpu_startup_entry+0x14/0x20 kernel/sched/idle.c:355
       start_kernel+0x82a/0x864 init/main.c:784
       secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
      Modules linked in:
      
      Reported-by: syzbot+f49d12d34f2321cf4df2@syzkaller.appspotmail.com
      Signed-off-by: NSean Young <sean@mess.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      78260a29
    • V
      media: cxusb: detect cxusb_ctrl_msg error in query · 94a94b60
      Vito Caputo 提交于
      commit ca8f245f284eeffa56f3b7a5eb6fc503159ee028 upstream.
      
      Don't use uninitialized ircode[] in cxusb_rc_query() when
      cxusb_ctrl_msg() fails to populate its contents.
      
      syzbot reported:
      
      dvb-usb: bulk message failed: -22 (1/-30591)
      =====================================================
      BUG: KMSAN: uninit-value in ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline]
      BUG: KMSAN: uninit-value in rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline]
      BUG: KMSAN: uninit-value in rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816
      CPU: 1 PID: 11436 Comm: kworker/1:2 Not tainted 5.3.0-rc7+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events dvb_usb_read_remote_control
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x191/0x1f0 lib/dump_stack.c:113
       kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108
       __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250
       bsearch+0x1dd/0x250 lib/bsearch.c:41
       ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline]
       rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline]
       rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816
       cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548
       dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261
       process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269
       worker_thread+0x111b/0x2460 kernel/workqueue.c:2415
       kthread+0x4b5/0x4f0 kernel/kthread.c:256
       ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355
      
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:150 [inline]
       kmsan_internal_chain_origin+0xd2/0x170 mm/kmsan/kmsan.c:314
       __msan_chain_origin+0x6b/0xe0 mm/kmsan/kmsan_instr.c:184
       rc_g_keycode_from_table drivers/media/rc/rc-main.c:583 [inline]
       rc_keydown+0x2c4/0x6f0 drivers/media/rc/rc-main.c:816
       cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548
       dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261
       process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269
       worker_thread+0x111b/0x2460 kernel/workqueue.c:2415
       kthread+0x4b5/0x4f0 kernel/kthread.c:256
       ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355
      
      Local variable description: ----ircode@cxusb_rc_query
      Variable was created at:
       cxusb_rc_query+0x4d/0x360 drivers/media/usb/dvb-usb/cxusb.c:543
       dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261
      Signed-off-by: NVito Caputo <vcaputo@pengaru.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NSean Young <sean@mess.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94a94b60
    • O
      media: b2c2-flexcop-usb: add sanity checking · 8b42c263
      Oliver Neukum 提交于
      commit 1b976fc6d684e3282914cdbe7a8d68fdce19095c upstream.
      
      The driver needs an isochronous endpoint to be present. It will
      oops in its absence. Add checking for it.
      
      Reported-by: syzbot+d93dff37e6a89431c158@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NSean Young <sean@mess.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b42c263
    • L
      media: uvcvideo: Fix error path in control parsing failure · 56be9f1b
      Laurent Pinchart 提交于
      commit 8c279e9394cade640ed86ec6c6645a0e7df5e0b6 upstream.
      
      When parsing the UVC control descriptors fails, the error path tries to
      cleanup a media device that hasn't been initialised, potentially
      resulting in a crash. Fix this by initialising the media device before
      the error handling path can be reached.
      
      Fixes: 5a254d75 ("[media] uvcvideo: Register a v4l2_device")
      Reported-by: syzbot+c86454eb3af9e8a4da20@syzkaller.appspotmail.com
      Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56be9f1b
    • K
      cpufreq: Add NULL checks to show() and store() methods of cpufreq · 61e73cf5
      Kai Shen 提交于
      commit e6e8df07268c1f75dd9215536e2ce4587b70f977 upstream.
      
      Add NULL checks to show() and store() in cpufreq.c to avoid attempts
      to invoke a NULL callback.
      
      Though some interfaces of cpufreq are set as read-only, users can
      still get write permission using chmod which can lead to a kernel
      crash, as follows:
      
      chmod +w /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
      echo 1 >  /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
      
      This bug was found in linux 4.19.
      Signed-off-by: NKai Shen <shenkai8@huawei.com>
      Reported-by: NFeilong Lin <linfeilong@huawei.com>
      Reviewed-by: NFeilong Lin <linfeilong@huawei.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      [ rjw: Subject & changelog ]
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61e73cf5
    • A
      media: usbvision: Fix races among open, close, and disconnect · f217cef9
      Alan Stern 提交于
      commit 9e08117c9d4efc1e1bc6fce83dab856d9fd284b6 upstream.
      
      Visual inspection of the usbvision driver shows that it suffers from
      three races between its open, close, and disconnect handlers.  In
      particular, the driver is careful to update its usbvision->user and
      usbvision->remove_pending flags while holding the private mutex, but:
      
      	usbvision_v4l2_close() and usbvision_radio_close() don't hold
      	the mutex while they check the value of
      	usbvision->remove_pending;
      
      	usbvision_disconnect() doesn't hold the mutex while checking
      	the value of usbvision->user; and
      
      	also, usbvision_v4l2_open() and usbvision_radio_open() don't
      	check whether the device has been unplugged before allowing
      	the user to open the device files.
      
      Each of these can potentially lead to usbvision_release() being called
      twice and use-after-free errors.
      
      This patch fixes the races by reading the flags while the mutex is
      still held and checking for pending removes before allowing an open to
      succeed.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f217cef9
    • A
      media: vivid: Fix wrong locking that causes race conditions on streaming stop · 467052f6
      Alexander Popov 提交于
      commit 6dcd5d7a7a29c1e4b8016a06aed78cd650cd8c27 upstream.
      
      There is the same incorrect approach to locking implemented in
      vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and
      sdr_cap_stop_streaming().
      
      These functions are called during streaming stopping with vivid_dev.mutex
      locked. And they all do the same mistake while stopping their kthreads,
      which need to lock this mutex as well. See the example from
      vivid_stop_generating_vid_cap():
        /* shutdown control thread */
        vivid_grab_controls(dev, false);
        mutex_unlock(&dev->mutex);
        kthread_stop(dev->kthread_vid_cap);
        dev->kthread_vid_cap = NULL;
        mutex_lock(&dev->mutex);
      
      But when this mutex is unlocked, another vb2_fop_read() can lock it
      instead of vivid_thread_vid_cap() and manipulate the buffer queue.
      That causes a use-after-free access later.
      
      To fix those issues let's:
        1. avoid unlocking the mutex in vivid_stop_generating_vid_cap(),
      vivid_stop_generating_vid_out() and sdr_cap_stop_streaming();
        2. use mutex_trylock() with schedule_timeout_uninterruptible() in
      the loops of the vivid kthread handlers.
      Signed-off-by: NAlexander Popov <alex.popov@linux.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Cc: <stable@vger.kernel.org>      # for v3.18 and up
      Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      467052f6
    • V
      media: vivid: Set vid_cap_streaming and vid_out_streaming to true · b73b28b1
      Vandana BN 提交于
      commit b4add02d2236fd5f568db141cfd8eb4290972eb3 upstream.
      
      When vbi stream is started, followed by video streaming,
      the vid_cap_streaming and vid_out_streaming were not being set to true,
      which would cause the video stream to stop when vbi stream is stopped.
      This patch allows to set vid_cap_streaming and vid_out_streaming to true.
      According to Hans Verkuil it appears that these 'if (dev->kthread_vid_cap)'
      checks are a left-over from the original vivid development and should never
      have been there.
      Signed-off-by: NVandana BN <bnvandana@gmail.com>
      Cc: <stable@vger.kernel.org>      # for v3.18 and up
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b73b28b1
    • O
      nfc: port100: handle command failure cleanly · af8071f5
      Oliver Neukum 提交于
      commit 5f9f0b11f0816b35867f2cf71e54d95f53f03902 upstream.
      
      If starting the transfer of a command suceeds but the transfer for the reply
      fails, it is not enough to initiate killing the transfer for the
      command may still be running. You need to wait for the killing to finish
      before you can reuse URB and buffer.
      
      Reported-and-tested-by: syzbot+711468aa5c3a1eabf863@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af8071f5
    • T
      ALSA: usb-audio: Fix NULL dereference at parsing BADD · 3510fb79
      Takashi Iwai 提交于
      commit 9435f2bb66874a0c4dd25e7c978957a7ca2c93b1 upstream.
      
      snd_usb_mixer_controls_badd() that parses UAC3 BADD profiles misses a
      NULL check for the given interfaces.  When a malformed USB descriptor
      is passed, this may lead to an Oops, as spotted by syzkaller.
      Skip the iteration if the interface doesn't exist for avoiding the
      crash.
      
      Fixes: 17156f23 ("ALSA: usb: add UAC3 BADD profiles support")
      Reported-by: syzbot+a36ab65c6653d7ccdd62@syzkaller.appspotmail.com
      Suggested-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191122112840.24797-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3510fb79
    • Y
      futex: Prevent robust futex exit race · 2819f403
      Yang Tao 提交于
      commit ca16d5bee59807bf04deaab0a8eccecd5061528c upstream.
      
      Robust futexes utilize the robust_list mechanism to allow the kernel to
      release futexes which are held when a task exits. The exit can be voluntary
      or caused by a signal or fault. This prevents that waiters block forever.
      
      The futex operations in user space store a pointer to the futex they are
      either locking or unlocking in the op_pending member of the per task robust
      list.
      
      After a lock operation has succeeded the futex is queued in the robust list
      linked list and the op_pending pointer is cleared.
      
      After an unlock operation has succeeded the futex is removed from the
      robust list linked list and the op_pending pointer is cleared.
      
      The robust list exit code checks for the pending operation and any futex
      which is queued in the linked list. It carefully checks whether the futex
      value is the TID of the exiting task. If so, it sets the OWNER_DIED bit and
      tries to wake up a potential waiter.
      
      This is race free for the lock operation but unlock has two race scenarios
      where waiters might not be woken up. These issues can be observed with
      regular robust pthread mutexes. PI aware pthread mutexes are not affected.
      
      (1) Unlocking task is killed after unlocking the futex value in user space
          before being able to wake a waiter.
      
              pthread_mutex_unlock()
                      |
                      V
              atomic_exchange_rel (&mutex->__data.__lock, 0)
                              <------------------------killed
                  lll_futex_wake ()                   |
                                                      |
                                                      |(__lock = 0)
                                                      |(enter kernel)
                                                      |
                                                      V
                                                  do_exit()
                                                  exit_mm()
                                                mm_release()
                                              exit_robust_list()
                                              handle_futex_death()
                                                      |
                                                      |(__lock = 0)
                                                      |(uval = 0)
                                                      |
                                                      V
              if ((uval & FUTEX_TID_MASK) != task_pid_vnr(curr))
                      return 0;
      
          The sanity check which ensures that the user space futex is owned by
          the exiting task prevents the wakeup of waiters which in consequence
          block infinitely.
      
      (2) Waiting task is killed after a wakeup and before it can acquire the
          futex in user space.
      
              OWNER                         WAITER
      				futex_wait()
         pthread_mutex_unlock()               |
                      |                       |
                      |(__lock = 0)           |
                      |                       |
                      V                       |
               futex_wake() ------------>  wakeup()
                                              |
                                              |(return to userspace)
                                              |(__lock = 0)
                                              |
                                              V
                              oldval = mutex->__data.__lock
                                                <-----------------killed
          atomic_compare_and_exchange_val_acq (&mutex->__data.__lock,  |
                              id | assume_other_futex_waiters, 0)      |
                                                                       |
                                                                       |
                                                         (enter kernel)|
                                                                       |
                                                                       V
                                                               do_exit()
                                                              |
                                                              |
                                                              V
                                              handle_futex_death()
                                              |
                                              |(__lock = 0)
                                              |(uval = 0)
                                              |
                                              V
              if ((uval & FUTEX_TID_MASK) != task_pid_vnr(curr))
                      return 0;
      
          The sanity check which ensures that the user space futex is owned
          by the exiting task prevents the wakeup of waiters, which seems to
          be correct as the exiting task does not own the futex value, but
          the consequence is that other waiters wont be woken up and block
          infinitely.
      
      In both scenarios the following conditions are true:
      
         - task->robust_list->list_op_pending != NULL
         - user space futex value == 0
         - Regular futex (not PI)
      
      If these conditions are met then it is reasonably safe to wake up a
      potential waiter in order to prevent the above problems.
      
      As this might be a false positive it can cause spurious wakeups, but the
      waiter side has to handle other types of unrelated wakeups, e.g. signals
      gracefully anyway. So such a spurious wakeup will not affect the
      correctness of these operations.
      
      This workaround must not touch the user space futex value and cannot set
      the OWNER_DIED bit because the lock value is 0, i.e. uncontended. Setting
      OWNER_DIED in this case would result in inconsistent state and subsequently
      in malfunction of the owner died handling in user space.
      
      The rest of the user space state is still consistent as no other task can
      observe the list_op_pending entry in the exiting tasks robust list.
      
      The eventually woken up waiter will observe the uncontended lock value and
      take it over.
      
      [ tglx: Massaged changelog and comment. Made the return explicit and not
        	depend on the subsequent check and added constants to hand into
        	handle_futex_death() instead of plain numbers. Fixed a few coding
      	style issues. ]
      
      Fixes: 0771dfef ("[PATCH] lightweight robust futexes: core")
      Signed-off-by: NYang Tao <yang.tao172@zte.com.cn>
      Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1573010582-35297-1-git-send-email-wang.yi59@zte.com.cn
      Link: https://lkml.kernel.org/r/20191106224555.943191378@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2819f403
    • A
      y2038: futex: Move compat implementation into futex.c · d3f8c58d
      Arnd Bergmann 提交于
      commit 04e7712f4460585e5eed5b853fd8b82a9943958f upstream.
      
      We are going to share the compat_sys_futex() handler between 64-bit
      architectures and 32-bit architectures that need to deal with both 32-bit
      and 64-bit time_t, and this is easier if both entry points are in the
      same file.
      
      In fact, most other system call handlers do the same thing these days, so
      let's follow the trend here and merge all of futex_compat.c into futex.c.
      
      In the process, a few minor changes have to be done to make sure everything
      still makes sense: handle_futex_death() and futex_cmpxchg_enabled() become
      local symbol, and the compat version of the fetch_robust_entry() function
      gets renamed to compat_fetch_robust_entry() to avoid a symbol clash.
      
      This is intended as a purely cosmetic patch, no behavior should
      change.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3f8c58d
    • N
      nbd: prevent memory leak · 344966da
      Navid Emamdoost 提交于
      commit 03bf73c315edca28f47451913177e14cd040a216 upstream.
      
      In nbd_add_socket when krealloc succeeds, if nsock's allocation fail the
      reallocted memory is leak. The correct behaviour should be assigning the
      reallocted memory to config->socks right after success.
      Reviewed-by: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      344966da
    • W
      x86/speculation: Fix redundant MDS mitigation message · ed7a3dde
      Waiman Long 提交于
      commit cd5a2aa89e847bdda7b62029d94e95488d73f6b2 upstream.
      
      Since MDS and TAA mitigations are inter-related for processors that are
      affected by both vulnerabilities, the followiing confusing messages can
      be printed in the kernel log:
      
        MDS: Vulnerable
        MDS: Mitigation: Clear CPU buffers
      
      To avoid the first incorrect message, defer the printing of MDS
      mitigation after the TAA mitigation selection has been done. However,
      that has the side effect of printing TAA mitigation first before MDS
      mitigation.
      
       [ bp: Check box is affected/mitigations are disabled first before
         printing and massage. ]
      Suggested-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Mark Gross <mgross@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20191115161445.30809-3-longman@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed7a3dde
    • W
      x86/speculation: Fix incorrect MDS/TAA mitigation status · 0af5ae26
      Waiman Long 提交于
      commit 64870ed1b12e235cfca3f6c6da75b542c973ff78 upstream.
      
      For MDS vulnerable processors with TSX support, enabling either MDS or
      TAA mitigations will enable the use of VERW to flush internal processor
      buffers at the right code path. IOW, they are either both mitigated
      or both not. However, if the command line options are inconsistent,
      the vulnerabilites sysfs files may not report the mitigation status
      correctly.
      
      For example, with only the "mds=off" option:
      
        vulnerabilities/mds:Vulnerable; SMT vulnerable
        vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT vulnerable
      
      The mds vulnerabilities file has wrong status in this case. Similarly,
      the taa vulnerability file will be wrong with mds mitigation on, but
      taa off.
      
      Change taa_select_mitigation() to sync up the two mitigation status
      and have them turned off if both "mds=off" and "tsx_async_abort=off"
      are present.
      
      Update documentation to emphasize the fact that both "mds=off" and
      "tsx_async_abort=off" have to be specified together for processors that
      are affected by both TAA and MDS to be effective.
      
       [ bp: Massage and add kernel-parameters.txt change too. ]
      
      Fixes: 1b42f017415b ("x86/speculation/taa: Add mitigation for TSX Async Abort")
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: linux-doc@vger.kernel.org
      Cc: Mark Gross <mgross@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20191115161445.30809-2-longman@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0af5ae26
    • A
      x86/insn: Fix awk regexp warnings · ed731209
      Alexander Kapshuk 提交于
      commit 700c1018b86d0d4b3f1f2d459708c0cdf42b521d upstream.
      
      gawk 5.0.1 generates the following regexp warnings:
      
        GEN      /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c
        awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape sequence `\:' is not a known regexp operator
        awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350: (FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape sequence `\&' is  not a known regexp operator
      
      Ealier versions of gawk are not known to generate these warnings. The
      gawk manual referenced below does not list characters ':' and '&' as
      needing escaping, so 'unescape' them. See
      
        https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html
      
      for more info.
      
      Running diff on the output generated by the script before and after
      applying the patch reported no differences.
      
       [ bp: Massage commit message. ]
      
      [ Caught the respective tools header discrepancy. ]
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NAlexander Kapshuk <alexander.kapshuk@gmail.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190924044659.3785-1-alexander.kapshuk@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed731209
    • A
      ARC: perf: Accommodate big-endian CPU · 99b933bb
      Alexey Brodkin 提交于
      commit 5effc09c4907901f0e71e68e5f2e14211d9a203f upstream.
      
      8-letter strings representing ARC perf events are stores in two
      32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc.
      
      And the same order of bytes in the word is used regardless CPU endianness.
      
      Which means in case of big-endian CPU core we need to swap bytes to get
      the same order as if it was on little-endian CPU.
      
      Otherwise we're seeing the following error message on boot:
      ------------------------->8----------------------
      ARC perf        : 8 counters (32 bits), 40 conditions, [overflow IRQ support]
      sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji'
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
      Stack Trace:
        arc_unwind_core+0xd4/0xfc
        dump_stack+0x64/0x80
        sysfs_warn_dup+0x46/0x58
        sysfs_add_file_mode_ns+0xb2/0x168
        create_files+0x70/0x2a0
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0
      Failed to register pmu: arc_pct, reason -17
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
      Stack Trace:
        arc_unwind_core+0xd4/0xfc
        dump_stack+0x64/0x80
        __warn+0x9c/0xd4
        warn_slowpath_fmt+0x22/0x2c
        perf_event_sysfs_init+0x70/0xa0
      ---[ end trace a75fb9a9837bd1ec ]---
      ------------------------->8----------------------
      
      What happens here we're trying to register more than one raw perf event
      with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters
      and encoded into two 32-bit words. In this particular case we deal with 2
      events:
       * "IJMP____" which counts all jump & branch instructions
       * "IJMPC___" which counts only conditional jumps & branches
      
      Those strings are split in two 32-bit words this way "IJMP" + "____" &
      "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core
      being big-endian then we read "PMJI" + "____" & "PMJI" + "___C".
      
      And since we interpret read array of ASCII letters as a null-terminated string
      on big-endian CPU we end up with 2 events of the same name "PMJI".
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      
      99b933bb
    • C
      ARM: 8904/1: skip nomap memblocks while finding the lowmem/highmem boundary · e02f1448
      Chester Lin 提交于
      commit 1d31999cf04c21709f72ceb17e65b54a401330da upstream.
      
      adjust_lowmem_bounds() checks every memblocks in order to find the boundary
      between lowmem and highmem. However some memblocks could be marked as NOMAP
      so they are not used by kernel, which should be skipped while calculating
      the boundary.
      Signed-off-by: NChester Lin <clin@suse.com>
      Reviewed-by: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e02f1448
    • G
      ocfs2: remove ocfs2_is_o2cb_active() · 046f0fcf
      Gang He 提交于
      commit a634644751c46238df58bbfe992e30c1668388db upstream.
      
      Remove ocfs2_is_o2cb_active().  We have similar functions to identify
      which cluster stack is being used via osb->osb_cluster_stack.
      
      Secondly, the current implementation of ocfs2_is_o2cb_active() is not
      totally safe.  Based on the design of stackglue, we need to get
      ocfs2_stack_lock before using ocfs2_stack related data structures, and
      that active_stack pointer can be NULL in the case of mount failure.
      
      Link: http://lkml.kernel.org/r/1495441079-11708-1-git-send-email-ghe@suse.comSigned-off-by: NGang He <ghe@suse.com>
      Reviewed-by: NJoseph Qi <jiangqi903@gmail.com>
      Reviewed-by: NEric Ren <zren@suse.com>
      Acked-by: NChangwei Ge <ge.changwei@h3c.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      046f0fcf
    • M
      net: phy: dp83867: increase SGMII autoneg timer duration · 36bef080
      Max Uvarov 提交于
      commit 1a97a477e666cbdededab93bd3754e508f0c09d7 upstream.
      
      After reset SGMII Autoneg timer is set to 2us (bits 6 and 5 are 01).
      That is not enough to finalize autonegatiation on some devices.
      Increase this timer duration to maximum supported 16ms.
      Signed-off-by: NMax Uvarov <muvarov@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      [ adapted for kernels without phy_modify_mmd ]
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36bef080
    • M
      net: phy: dp83867: fix speed 10 in sgmii mode · 87997a78
      Max Uvarov 提交于
      commit 333061b924539c0de081339643f45514f5f1c1e6 upstream.
      
      For supporting 10Mps speed in SGMII mode DP83867_10M_SGMII_RATE_ADAPT bit
      of DP83867_10M_SGMII_CFG register has to be cleared by software.
      That does not affect speeds 100 and 1000 so can be done on init.
      Signed-off-by: NMax Uvarov <muvarov@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      [ adapted for kernels without phy_modify_mmd ]
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87997a78
    • D
      mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span() · 5779cbc9
      David Hildenbrand 提交于
      commit 7ce700bf11b5e2cb84e4352bbdf2123a7a239c84 upstream.
      
      Let's limit shrinking to !ZONE_DEVICE so we can fix the current code.
      We should never try to touch the memmap of offline sections where we
      could have uninitialized memmaps and could trigger BUGs when calling
      page_to_nid() on poisoned pages.
      
      There is no reliable way to distinguish an uninitialized memmap from an
      initialized memmap that belongs to ZONE_DEVICE, as we don't have
      anything like SECTION_IS_ONLINE we can use similar to
      pfn_to_online_section() for !ZONE_DEVICE memory.
      
      E.g., set_zone_contiguous() similarly relies on pfn_to_online_section()
      and will therefore never set a ZONE_DEVICE zone consecutive.  Stopping
      to shrink the ZONE_DEVICE therefore results in no observable changes,
      besides /proc/zoneinfo indicating different boundaries - something we
      can totally live with.
      
      Before commit d0dc12e8 ("mm/memory_hotplug: optimize memory
      hotplug"), the memmap was initialized with 0 and the node with the right
      value.  So the zone might be wrong but not garbage.  After that commit,
      both the zone and the node will be garbage when touching uninitialized
      memmaps.
      
      Toshiki reported a BUG (race between delayed initialization of
      ZONE_DEVICE memmaps without holding the memory hotplug lock and
      concurrent zone shrinking).
      
        https://lkml.org/lkml/2019/11/14/1040
      
      "Iteration of create and destroy namespace causes the panic as below:
      
            kernel BUG at mm/page_alloc.c:535!
            CPU: 7 PID: 2766 Comm: ndctl Not tainted 5.4.0-rc4 #6
            Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
            RIP: 0010:set_pfnblock_flags_mask+0x95/0xf0
            Call Trace:
             memmap_init_zone_device+0x165/0x17c
             memremap_pages+0x4c1/0x540
             devm_memremap_pages+0x1d/0x60
             pmem_attach_disk+0x16b/0x600 [nd_pmem]
             nvdimm_bus_probe+0x69/0x1c0
             really_probe+0x1c2/0x3e0
             driver_probe_device+0xb4/0x100
             device_driver_attach+0x4f/0x60
             bind_store+0xc9/0x110
             kernfs_fop_write+0x116/0x190
             vfs_write+0xa5/0x1a0
             ksys_write+0x59/0xd0
             do_syscall_64+0x5b/0x180
             entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
        While creating a namespace and initializing memmap, if you destroy the
        namespace and shrink the zone, it will initialize the memmap outside
        the zone and trigger VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page),
        pfn), page) in set_pfnblock_flags_mask()."
      
      This BUG is also mitigated by this commit, where we for now stop to
      shrink the ZONE_DEVICE zone until we can do it in a safe and clean way.
      
      Link: http://lkml.kernel.org/r/20191006085646.5768-5-david@redhat.com
      Fixes: f1dd2cd1 ("mm, memory_hotplug: do not associate hotadded memory to zones until online")	[visible after d0dc12e8]
      Signed-off-by: NDavid Hildenbrand <david@redhat.com>
      Reported-by: NAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Reported-by: NToshiki Fukasawa <t-fukasawa@vx.jp.nec.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Damian Tometzki <damian.tometzki@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Halil Pasic <pasic@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Ira Weiny <ira.weiny@intel.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Jun Yao <yaojun8558363@gmail.com>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Pankaj Gupta <pagupta@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pavel Tatashin <pavel.tatashin@microsoft.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Qian Cai <cai@lca.pw>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Steve Capper <steve.capper@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Wei Yang <richardw.yang@linux.intel.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Yu Zhao <yuzhao@google.com>
      Cc: <stable@vger.kernel.org>	[4.13+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NDavid Hildenbrand <david@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5779cbc9
    • J
      md/raid10: prevent access of uninitialized resync_pages offset · a268d985
      John Pittman 提交于
      commit 45422b704db392a6d79d07ee3e3670b11048bd53 upstream.
      
      Due to unneeded multiplication in the out_free_pages portion of
      r10buf_pool_alloc(), when using a 3-copy raid10 layout, it is
      possible to access a resync_pages offset that has not been
      initialized.  This access translates into a crash of the system
      within resync_free_pages() while passing a bad pointer to
      put_page().  Remove the multiplication, preventing access to the
      uninitialized area.
      
      Fixes: f0250618 ("md: raid10: don't use bio's vec table to manage resync pages")
      Cc: stable@vger.kernel.org # 4.12+
      Signed-off-by: NJohn Pittman <jpittman@redhat.com>
      Suggested-by: NDavid Jeffery <djeffery@redhat.com>
      Reviewed-by: NLaurence Oberman <loberman@redhat.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a268d985
    • D
      ath9k_hw: fix uninitialized variable data · f8dc0350
      Denis Efremov 提交于
      commit 80e84f36412e0c5172447b6947068dca0d04ee82 upstream.
      
      Currently, data variable in ar9003_hw_thermo_cal_apply() could be
      uninitialized if ar9300_otp_read_word() will fail to read the value.
      Initialize data variable with 0 to prevent an undefined behavior. This
      will be enough to handle error case when ar9300_otp_read_word() fails.
      
      Fixes: 80fe43f2 ("ath9k_hw: Read and configure thermocal for AR9462")
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDenis Efremov <efremov@linux.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8dc0350
    • H
      ath10k: Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe · f0cfe983
      Hui Peng 提交于
      commit bfd6e6e6c5d2ee43a3d9902b36e01fc7527ebb27 upstream.
      
      The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
      are initialized to point to the containing `ath10k_usb` object
      according to endpoint descriptors read from the device side, as shown
      below in `ath10k_usb_setup_pipe_resources`:
      
      for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
              endpoint = &iface_desc->endpoint[i].desc;
      
              // get the address from endpoint descriptor
              pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb,
                                                      endpoint->bEndpointAddress,
                                                      &urbcount);
              ......
              // select the pipe object
              pipe = &ar_usb->pipes[pipe_num];
      
              // initialize the ar_usb field
              pipe->ar_usb = ar_usb;
      }
      
      The driver assumes that the addresses reported in endpoint
      descriptors from device side  to be complete. If a device is
      malicious and does not report complete addresses, it may trigger
      NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and
      `ath10k_usb_free_urb_to_pipe`.
      
      This patch fixes the bug by preventing potential NULL-ptr-deref.
      Signed-off-by: NHui Peng <benquike@gmail.com>
      Reported-by: NHui Peng <benquike@gmail.com>
      Reported-by: NMathias Payer <mathias.payer@nebelwelt.net>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [groeck: Add driver tag to subject, fix build warning]
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0cfe983