1. 03 Apr, 2019 40 commits
    • Chen-Yu Tsai's avatar
      phy: sun4i-usb: Support set_mode to USB_HOST for non-OTG PHYs · d05885ad
      Chen-Yu Tsai authored
      commit 1396929e upstream.
      
      While only the first PHY supports mode switching, the remaining PHYs
      work in USB host mode. They should support set_mode with mode=USB_HOST
      instead of failing. This is especially needed now that the USB core does
      set_mode for all USB ports, which was added in commit b97a3134 ("usb:
      core: comply to PHY framework").
      
      Make set_mode with mode=USB_HOST a no-op instead of failing for the
      non-OTG USB PHYs.
      
      Fixes: 6ba43c29 ("phy-sun4i-usb: Add support for phy_set_mode")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d05885ad
    • Axel Lin's avatar
      gpio: adnp: Fix testing wrong value in adnp_gpio_direction_input · 5d4cc25d
      Axel Lin authored
      commit c5bc6e52 upstream.
      
      Current code test wrong value so it does not verify if the written
      data is correctly read back. Fix it.
      Also make it return -EPERM if read value does not match written bit,
      just like it done for adnp_gpio_direction_output().
      
      Fixes: 5e969a40 ("gpio: Add Avionic Design N-bit GPIO expander support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAxel Lin <axel.lin@ingics.com>
      Reviewed-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d4cc25d
    • Kangjie Lu's avatar
      gpio: exar: add a check for the return value of ida_simple_get fails · e708e5db
      Kangjie Lu authored
      commit 7ecced09 upstream.
      
      ida_simple_get may fail and return a negative error number.
      The fix checks its return value; if it fails, go to err_destroy.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e708e5db
    • Eric Biggers's avatar
      drm/vgem: fix use-after-free when drm_gem_handle_create() fails · 2ea1c197
      Eric Biggers authored
      commit 21d2b122 upstream.
      
      If drm_gem_handle_create() fails in vgem_gem_create(), then the
      drm_vgem_gem_object is freed twice: once when the reference is dropped
      by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
      
      This was hit by syzkaller using fault injection.
      
      Fix it by skipping the second free.
      
      Reported-by: syzbot+e73f2fb5ed5a5df36d33@syzkaller.appspotmail.com
      Fixes: af33a919 ("drm/vgem: Enable dmabuf import interfaces")
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190226214451.195123-1-ebiggers@kernel.orgSigned-off-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ea1c197
    • YueHaibing's avatar
      fs/proc/proc_sysctl.c: fix NULL pointer dereference in put_links · 0d9ef3f5
      YueHaibing authored
      commit 23da9588 upstream.
      
      Syzkaller reports:
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN PTI
      CPU: 1 PID: 5373 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:put_links+0x101/0x440 fs/proc/proc_sysctl.c:1599
      Code: 00 0f 85 3a 03 00 00 48 8b 43 38 48 89 44 24 20 48 83 c0 38 48 89 c2 48 89 44 24 28 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 fe 02 00 00 48 8b 74 24 20 48 c7 c7 60 2a 9d 91
      RSP: 0018:ffff8881d828f238 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff8881e01b1140 RCX: ffffffff8ee98267
      RDX: 0000000000000007 RSI: ffffc90001479000 RDI: ffff8881e01b1178
      RBP: dffffc0000000000 R08: ffffed103ee27259 R09: ffffed103ee27259
      R10: 0000000000000001 R11: ffffed103ee27258 R12: fffffffffffffff4
      R13: 0000000000000006 R14: ffff8881f59838c0 R15: dffffc0000000000
      FS:  00007f072254f700(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fff8b286668 CR3: 00000001f0542002 CR4: 00000000007606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       drop_sysctl_table+0x152/0x9f0 fs/proc/proc_sysctl.c:1629
       get_subdir fs/proc/proc_sysctl.c:1022 [inline]
       __register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335
       br_netfilter_init+0xbc/0x1000 [br_netfilter]
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f072254ec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003
      RBP: 00007f072254ec70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f072254f6bc
      R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
      Modules linked in: br_netfilter(+) dvb_usb_dibusb_mc_common dib3000mc dibx000_common dvb_usb_dibusb_common dvb_usb_dw2102 dvb_usb classmate_laptop palmas_regulator cn videobuf2_v4l2 v4l2_common snd_soc_bd28623 mptbase snd_usb_usx2y snd_usbmidi_lib snd_rawmidi wmi libnvdimm lockd sunrpc grace rc_kworld_pc150u rc_core rtc_da9063 sha1_ssse3 i2c_cros_ec_tunnel adxl34x_spi adxl34x nfnetlink lib80211 i5500_temp dvb_as102 dvb_core videobuf2_common videodev media videobuf2_vmalloc videobuf2_memops udc_core lnbp22 leds_lp3952 hid_roccat_ryos s1d13xxxfb mtd vport_geneve openvswitch nf_conncount nf_nat_ipv6 nsh geneve udp_tunnel ip6_udp_tunnel snd_soc_mt6351 sis_agp phylink snd_soc_adau1761_spi snd_soc_adau1761 snd_soc_adau17x1 snd_soc_core snd_pcm_dmaengine ac97_bus snd_compress snd_soc_adau_utils snd_soc_sigmadsp_regmap snd_soc_sigmadsp raid_class hid_roccat_konepure hid_roccat_common hid_roccat c2port_duramar2150 core mdio_bcm_unimac iptable_security iptable_raw iptable_mangle
       iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim devlink vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel joydev mousedev ide_pci_generic piix aesni_intel aes_x86_64 ide_core crypto_simd atkbd cryptd glue_helper serio_raw ata_generic pata_acpi i2c_piix4 floppy sch_fq_codel ip_tables x_tables ipv6 [last unloaded: lm73]
      Dumping ftrace buffer:
         (ftrace buffer empty)
      ---[ end trace 770020de38961fd0 ]---
      
      A new dir entry can be created in get_subdir and its 'header->parent' is
      set to NULL.  Only after insert_header success, it will be set to 'dir',
      otherwise 'header->parent' is set to NULL and drop_sysctl_table is called.
      However in err handling path of get_subdir, drop_sysctl_table also be
      called on 'new->header' regardless its value of parent pointer.  Then
      put_links is called, which triggers NULL-ptr deref when access member of
      header->parent.
      
      In fact we have multiple error paths which call drop_sysctl_table() there,
      upon failure on insert_links() we also call drop_sysctl_table().And even
      in the successful case on __register_sysctl_table() we still always call
      drop_sysctl_table().This patch fix it.
      
      Link: http://lkml.kernel.org/r/20190314085527.13244-1-yuehaibing@huawei.com
      Fixes: 0e47c99d ("sysctl: Replace root_list with links between sysctl_table_sets")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Acked-by: default avatarLuis Chamberlain <mcgrof@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: <stable@vger.kernel.org>    [3.4+]
      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>
      0d9ef3f5
    • Wentao Wang's avatar
      Disable kgdboc failed by echo space to /sys/module/kgdboc/parameters/kgdboc · 0209f339
      Wentao Wang authored
      commit 3ec80029 upstream.
      
      Echo "" to /sys/module/kgdboc/parameters/kgdboc will fail with "No such
      device” error.
      
      This is caused by function "configure_kgdboc" who init err to ENODEV
      when the config is empty (legal input) the code go out with ENODEV
      returned.
      
      Fixes: 2dd45316 ("kgdboc: Fix restrict error")
      Signed-off-by: default avatarWentao Wang <witallwang@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0209f339
    • Bjørn Mork's avatar
      USB: serial: option: add Olicard 600 · 29c87d22
      Bjørn Mork authored
      commit 84f3b43f upstream.
      
      This is a Qualcomm based device with a QMI function on interface 4.
      It is mode switched from 2020:2030 using a standard eject message.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2020 ProdID=2031 Rev= 2.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
      E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
      E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      [ johan: use tabs to align comments in adjacent lines ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29c87d22
    • Kristian Evensen's avatar
      USB: serial: option: add support for Quectel EM12 · 7502ab66
      Kristian Evensen authored
      commit d1252f02 upstream.
      
      The Quectel EM12 is a Cat. 12 LTE modem. It behaves in the exactly the
      same way as the EP06 (including the dynamic configuration behavior), so
      the same checks on reserved interfaces, etc. are needed.
      Signed-off-by: default avatarKristian Evensen <kristian.evensen@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7502ab66
    • Mans Rullgard's avatar
      USB: serial: option: set driver_info for SIM5218 and compatibles · d93cb349
      Mans Rullgard authored
      commit f8df5c2c upstream.
      
      The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4
      of which are serial ports.  The fifth is a network interface supported
      by the qmi-wwan driver.  Furthermore, the serial ports do not support
      modem control signals.  Add driver_info flags to reflect this.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      Fixes: ec0cd94d ("usb: option: add SIMCom SIM5218")
      Cc: stable <stable@vger.kernel.org>	# 3.2
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d93cb349
    • Lin Yi's avatar
      USB: serial: mos7720: fix mos_parport refcount imbalance on error path · 079d7d8e
      Lin Yi authored
      commit 2908b076 upstream.
      
      The write_parport_reg_nonblock() helper takes a reference to the struct
      mos_parport, but failed to release it in a couple of error paths after
      allocation failures, leading to a memory leak.
      
      Johan said that move the kref_get() and mos_parport assignment to the
      end of urbtrack initialisation is a better way, so move it. and
      mos_parport do not used until urbtrack initialisation.
      Signed-off-by: default avatarLin Yi <teroincn@163.com>
      Fixes: b69578df ("USB: usbserial: mos7720: add support for parallel port on moschip 7715")
      Cc: stable <stable@vger.kernel.org>     # 2.6.35
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      079d7d8e
    • George McCollister's avatar
      USB: serial: ftdi_sio: add additional NovaTech products · 40c93e68
      George McCollister authored
      commit 422c2537 upstream.
      
      Add PIDs for the NovaTech OrionLX+ and Orion I/O so they can be
      automatically detected.
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40c93e68
    • Greg Kroah-Hartman's avatar
      USB: serial: cp210x: add new device id · e76f00ea
      Greg Kroah-Hartman authored
      commit a595ecdd upstream.
      
      Lorenz Messtechnik has a device that is controlled by the cp210x driver,
      so add the device id to the driver.  The device id was provided by
      Silicon-Labs for the devices from this vendor.
      Reported-by: default avatarUli <t9cpu@web.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e76f00ea
    • Hoan Nguyen An's avatar
      serial: sh-sci: Fix setting SCSCR_TIE while transferring data · be8c9346
      Hoan Nguyen An authored
      commit 93bcefd4 upstream.
      
      We disable transmission interrupt (clear SCSCR_TIE) after all data has been transmitted
      (if uart_circ_empty(xmit)). While transmitting, if the data is still in the tty buffer,
      re-enable the SCSCR_TIE bit, which was done at sci_start_tx().
      This is unnecessary processing, wasting CPU operation if the data transmission length is large.
      And further, transmit end, FIFO empty bits disabling have also been performed in the step above.
      Signed-off-by: default avatarHoan Nguyen An <na-hoan@jinso.co.jp>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be8c9346
    • Aditya Pakki's avatar
      serial: max310x: Fix to avoid potential NULL pointer dereference · 0d42abfa
      Aditya Pakki authored
      commit 3a10e3dd upstream.
      
      of_match_device can return a NULL pointer when matching device is not
      found. This patch avoids a scenario causing NULL pointer derefernce.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d42abfa
    • Malcolm Priestley's avatar
      staging: vt6655: Fix interrupt race condition on device start up. · 6c8f9d93
      Malcolm Priestley authored
      commit 3b9c2f2e upstream.
      
      It appears on some slower systems that the driver can find its way
      out of the workqueue while the interrupt is disabled by continuous polling
      by it.
      
      Move MACvIntEnable to vnt_interrupt_work so that it is always enabled
      on all routes out of vnt_interrupt_process.
      
      Move MACvIntDisable so that the device doesn't keep polling the system
      while the workqueue is being processed.
      Signed-off-by: default avatarMalcolm Priestley <tvboxspy@gmail.com>
      CC: stable@vger.kernel.org # v4.2+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c8f9d93
    • Malcolm Priestley's avatar
      staging: vt6655: Remove vif check from vnt_interrupt · 03f4d949
      Malcolm Priestley authored
      commit cc26358f upstream.
      
      A check for vif is made in vnt_interrupt_work.
      
      There is a small chance of leaving interrupt disabled while vif
      is NULL and the work hasn't been scheduled.
      Signed-off-by: default avatarMalcolm Priestley <tvboxspy@gmail.com>
      CC: stable@vger.kernel.org # v4.2+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03f4d949
    • Ian Abbott's avatar
      staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest · 7787d644
      Ian Abbott authored
      commit bafd9c64 upstream.
      
      `ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO
      subdevice (subdevice 2) of supported National Instruments M-series
      cards.  It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST`
      ioctls for this subdevice.  There are two causes for a possible
      divide-by-zero error when validating that the `stop_arg` member of the
      passed-in command is not too large.
      
      The first cause for the divide-by-zero is that calls to
      `comedi_bytes_per_scan()` are only valid once the command has been
      copied to `s->async->cmd`, but that copy is only done for the
      `COMEDI_CMD` ioctl.  For the `COMEDI_CMDTEST` ioctl, it will use
      whatever was left there by the previous `COMEDI_CMD` ioctl, if any.
      (This is very likely, as it is usual for the application to use
      `COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous,
      valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()`
      will return 0, so the subsequent division in `ni_cdio_cmdtest()` of
      `s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a
      divide-by-zero error.  To fix this error, call a new function
      `comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing
      `comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for
      its calculations.  (Also refactor `comedi_bytes_per_scan()` to call the
      new function.)
      
      Once the first cause for the divide-by-zero has been fixed, the second
      cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if
      the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0.
      Fix it by only performing the division (and validating that `stop_arg`
      is no more than the maximum value) if `comedi_bytes_per_scan_cmd()`
      returns a non-zero value.
      
      The problem was reported on the COMEDI mailing list here:
      https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKMReported-by: default avatarIvan Vasilyev <grabesstimme@gmail.com>
      Tested-by: default avatarIvan Vasilyev <grabesstimme@gmail.com>
      Fixes: f164cbf9 ("staging: comedi: ni_mio_common: add finite regeneration to dio output")
      Cc: <stable@vger.kernel.org> # 4.6+
      Cc: Spencer E. Olson <olsonse@umich.edu>
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7787d644
    • Kangjie Lu's avatar
      tty: atmel_serial: fix a potential NULL pointer dereference · 4f490894
      Kangjie Lu authored
      commit c85be041 upstream.
      
      In case dmaengine_prep_dma_cyclic fails, the fix returns a proper
      error code to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Fixes: 34df42f5 ("serial: at91: add rx dma support")
      Acked-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f490894
    • Steffen Maier's avatar
      scsi: zfcp: fix scsi_eh host reset with port_forced ERP for non-NPIV FCP devices · 2689a646
      Steffen Maier authored
      commit 242ec145 upstream.
      
      Suppose more than one non-NPIV FCP device is active on the same channel.
      Send I/O to storage and have some of the pending I/O run into a SCSI
      command timeout, e.g. due to bit errors on the fibre. Now the error
      situation stops. However, we saw FCP requests continue to timeout in the
      channel. The abort will be successful, but the subsequent TUR fails.
      Scsi_eh starts. The LUN reset fails. The target reset fails.  The host
      reset only did an FCP device recovery. However, for non-NPIV FCP devices,
      this does not close and reopen ports on the SAN-side if other non-NPIV FCP
      device(s) share the same open ports.
      
      In order to resolve the continuing FCP request timeouts, we need to
      explicitly close and reopen ports on the SAN-side.
      
      This was missing since the beginning of zfcp in v2.6.0 history commit
      ea127f97 ("[PATCH] s390 (7/7): zfcp host adapter.").
      
      Note: The FSF requests for forced port reopen could run into FSF request
      timeouts due to other reasons. This would trigger an internal FCP device
      recovery. Pending forced port reopen recoveries would get dismissed. So
      some ports might not get fully reopened during this host reset handler.
      However, subsequent I/O would trigger the above described escalation and
      eventually all ports would be forced reopen to resolve any continuing FCP
      request timeouts due to earlier bit errors.
      Signed-off-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: <stable@vger.kernel.org> #3.0+
      Reviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2689a646
    • Steffen Maier's avatar
      scsi: zfcp: fix rport unblock if deleted SCSI devices on Scsi_Host · 69476e1f
      Steffen Maier authored
      commit fe67888f upstream.
      
      An already deleted SCSI device can exist on the Scsi_Host and remain there
      because something still holds a reference.  A new SCSI device with the same
      H:C:T:L and FCP device, target port WWPN, and FCP LUN can be created.  When
      we try to unblock an rport, we still find the deleted SCSI device and
      return early because the zfcp_scsi_dev of that SCSI device is not
      ZFCP_STATUS_COMMON_UNBLOCKED. Hence we miss to unblock the rport, even if
      the new proper SCSI device would be in good state.
      
      Therefore, skip deleted SCSI devices when iterating the sdevs of the shost.
      [cf. __scsi_device_lookup{_by_target}() or scsi_device_get()]
      
      The following abbreviated trace sequence can indicate such problem:
      
      Area           : REC
      Tag            : ersfs_3
      LUN            : 0x4045400300000000
      WWPN           : 0x50050763031bd327
      LUN status     : 0x40000000     not ZFCP_STATUS_COMMON_UNBLOCKED
      Ready count    : n		not incremented yet
      Running count  : 0x00000000
      ERP want       : 0x01
      ERP need       : 0xc1		ZFCP_ERP_ACTION_NONE
      
      Area           : REC
      Tag            : ersfs_3
      LUN            : 0x4045400300000000
      WWPN           : 0x50050763031bd327
      LUN status     : 0x41000000
      Ready count    : n+1
      Running count  : 0x00000000
      ERP want       : 0x01
      ERP need       : 0x01
      
      ...
      
      Area           : REC
      Level          : 4		only with increased trace level
      Tag            : ertru_l
      LUN            : 0x4045400300000000
      WWPN           : 0x50050763031bd327
      LUN status     : 0x40000000
      Request ID     : 0x0000000000000000
      ERP status     : 0x01800000
      ERP step       : 0x1000
      ERP action     : 0x01
      ERP count      : 0x00
      
      NOT followed by a trace record with tag "scpaddy"
      for WWPN 0x50050763031bd327.
      Signed-off-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Fixes: 6f2ce1c6 ("scsi: zfcp: fix rport unblock race with LUN recovery")
      Cc: <stable@vger.kernel.org> #2.6.32+
      Reviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69476e1f
    • Martin K. Petersen's avatar
      scsi: sd: Quiesce warning if device does not report optimal I/O size · f3b89755
      Martin K. Petersen authored
      commit 1d5de5bd upstream.
      
      Commit a83da8a4 ("scsi: sd: Optimal I/O size should be a multiple
      of physical block size") split one conditional into several separate
      statements in an effort to provide more accurate warning messages when
      a device reports a nonsensical value. However, this reorganization
      accidentally dropped the precondition of the reported value being
      larger than zero. This lead to a warning getting emitted on devices
      that do not report an optimal I/O size at all.
      
      Remain silent if a device does not report an optimal I/O size.
      
      Fixes: a83da8a4 ("scsi: sd: Optimal I/O size should be a multiple of physical block size")
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarHussam Al-Tayeb <ht990332@gmx.com>
      Tested-by: default avatarHussam Al-Tayeb <ht990332@gmx.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f3b89755
    • Bart Van Assche's avatar
      scsi: sd: Fix a race between closing an sd device and sd I/O · 683c14fb
      Bart Van Assche authored
      commit c14a5726 upstream.
      
      The scsi_end_request() function calls scsi_cmd_to_driver() indirectly and
      hence needs the disk->private_data pointer. Avoid that that pointer is
      cleared before all affected I/O requests have finished. This patch avoids
      that the following crash occurs:
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      Call trace:
       scsi_mq_uninit_cmd+0x1c/0x30
       scsi_end_request+0x7c/0x1b8
       scsi_io_completion+0x464/0x668
       scsi_finish_command+0xbc/0x160
       scsi_eh_flush_done_q+0x10c/0x170
       sas_scsi_recover_host+0x84c/0xa98 [libsas]
       scsi_error_handler+0x140/0x5b0
       kthread+0x100/0x12c
       ret_from_fork+0x10/0x18
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Ming Lei <ming.lei@redhat.com>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Johannes Thumshirn <jthumshirn@suse.de>
      Cc: Jason Yan <yanaijie@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Reported-by: default avatarJason Yan <yanaijie@huawei.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      683c14fb
    • Darrick J. Wong's avatar
      ocfs2: fix inode bh swapping mixup in ocfs2_reflink_inodes_lock · e8bf3395
      Darrick J. Wong authored
      commit e6a9467e upstream.
      
      ocfs2_reflink_inodes_lock() can swap the inode1/inode2 variables so that
      we always grab cluster locks in order of increasing inode number.
      
      Unfortunately, we forget to swap the inode record buffer head pointers
      when we've done this, which leads to incorrect bookkeepping when we're
      trying to make the two inodes have the same refcount tree.
      
      This has the effect of causing filesystem shutdowns if you're trying to
      reflink data from inode 100 into inode 97, where inode 100 already has a
      refcount tree attached and inode 97 doesn't.  The reflink code decides
      to copy the refcount tree pointer from 100 to 97, but uses inode 97's
      inode record to open the tree root (which it doesn't have) and blows up.
      This issue causes filesystem shutdowns and metadata corruption!
      
      Link: http://lkml.kernel.org/r/20190312214910.GK20533@magnolia
      Fixes: 29ac8e85 ("ocfs2: implement the VFS clone_range, copy_range, and dedupe_range features")
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarJoseph Qi <jiangqi903@gmail.com>
      Cc: Mark Fasheh <mfasheh@versity.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <joseph.qi@huawei.com>
      Cc: <stable@vger.kernel.org>
      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>
      e8bf3395
    • Tetsuo Handa's avatar
      fs/open.c: allow opening only regular files during execve() · 26c3a3b9
      Tetsuo Handa authored
      commit 73601ea5 upstream.
      
      syzbot is hitting lockdep warning [1] due to trying to open a fifo
      during an execve() operation.  But we don't need to open non regular
      files during an execve() operation, for all files which we will need are
      the executable file itself and the interpreter programs like /bin/sh and
      ld-linux.so.2 .
      
      Since the manpage for execve(2) says that execve() returns EACCES when
      the file or a script interpreter is not a regular file, and the manpage
      for uselib(2) says that uselib() can return EACCES, and we use
      FMODE_EXEC when opening for execve()/uselib(), we can bail out if a non
      regular file is requested with FMODE_EXEC set.
      
      Since this deadlock followed by khungtaskd warnings is trivially
      reproducible by a local unprivileged user, and syzbot's frequent crash
      due to this deadlock defers finding other bugs, let's workaround this
      deadlock until we get a chance to find a better solution.
      
      [1] https://syzkaller.appspot.com/bug?id=b5095bfec44ec84213bac54742a82483aad578ce
      
      Link: http://lkml.kernel.org/r/1552044017-7890-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jpReported-by: default avatarsyzbot <syzbot+e93a80c1bb7c5c56e522461c149f8bf55eab1b2b@syzkaller.appspotmail.com>
      Fixes: 8924feff ("splice: lift pipe_lock out of splice_to_pipe()")
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Eric Biggers <ebiggers3@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@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>
      26c3a3b9
    • Fredrik Noring's avatar
      kbuild: modversions: Fix relative CRC byte order interpretation · e75c894d
      Fredrik Noring authored
      commit 54a7151b upstream.
      
      Fix commit 56067812 ("kbuild: modversions: add infrastructure for
      emitting relative CRCs") where CRCs are interpreted in host byte order
      rather than proper kernel byte order. The bug is conditional on
      CONFIG_MODULE_REL_CRCS.
      
      For example, when loading a BE module into a BE kernel compiled with a LE
      system, the error "disagrees about version of symbol module_layout" is
      produced. A message such as "Found checksum D7FA6856 vs module 5668FAD7"
      will be given with debug enabled, which indicates an obvious endian
      problem within __kcrctab within the kernel image.
      
      The general solution is to use the macro TO_NATIVE, as is done in
      similar cases throughout modpost.c. With this correction it has been
      verified that a BE kernel compiled with a LE system accepts BE modules.
      
      This change has also been verified with a LE kernel compiled with a LE
      system, in which case TO_NATIVE returns its value unmodified since the
      byte orders match. This is by far the common case.
      
      Fixes: 56067812 ("kbuild: modversions: add infrastructure for emitting relative CRCs")
      Signed-off-by: default avatarFredrik Noring <noring@nocrew.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e75c894d
    • Kailang Yang's avatar
      ALSA: hda/realtek - Add support headset mode for New DELL WYSE NB · fe2d6d04
      Kailang Yang authored
      commit da484d00 upstream.
      
      Enable headset mode support for new WYSE NB platform.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe2d6d04
    • Kailang Yang's avatar
      ALSA: hda/realtek - Add support headset mode for DELL WYSE AIO · e1b7eaa9
      Kailang Yang authored
      commit 136824ef upstream.
      
      This patch will enable WYSE AIO for Headset mode.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1b7eaa9
    • Takashi Iwai's avatar
      ALSA: pcm: Don't suspend stream in unrecoverable PCM state · 6182bdf0
      Takashi Iwai authored
      commit 113ce081 upstream.
      
      Currently PCM core sets each opened stream forcibly to SUSPENDED state
      via snd_pcm_suspend_all() call, and the user-space is responsible for
      re-triggering the resume manually either via snd_pcm_resume() or
      prepare call.  The scheme works fine usually, but there are corner
      cases where the stream can't be resumed by that call: the streams
      still in OPEN state before finishing hw_params.  When they are
      suspended, user-space cannot perform resume or prepare because they
      haven't been set up yet.  The only possible recovery is to re-open the
      device, which isn't nice at all.  Similarly, when a stream is in
      DISCONNECTED state, it makes no sense to change it to SUSPENDED
      state.  Ditto for in SETUP state; which you can re-prepare directly.
      
      So, this patch addresses these issues by filtering the PCM streams to
      be suspended by checking the PCM state.  When a stream is in either
      OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend
      action is skipped.
      
      To be noted, this problem was originally reported for the PCM runtime
      PM on HD-audio.  And, the runtime PM problem itself was already
      addressed (although not intended) by the code refactoring commits
      3d21ef0b ("ALSA: pcm: Suspend streams globally via device type PM
      ops") and 17bc4815 ("ALSA: pci: Remove superfluous
      snd_pcm_suspend*() calls").  These commits eliminated the
      snd_pcm_suspend*() calls from the runtime PM suspend callback code
      path, hence the racy OPEN state won't appear while runtime PM.
      (FWIW, the race window is between snd_pcm_open_substream() and the
      first power up in azx_pcm_open().)
      
      Although the runtime PM issue was already "fixed", the same problem is
      still present for the system PM, hence this patch is still needed.
      And for stable trees, this patch alone should suffice for fixing the
      runtime PM problem, too.
      Reported-and-tested-by: default avatarJon Hunter <jonathanh@nvidia.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>
      6182bdf0
    • Takashi Iwai's avatar
      ALSA: pcm: Fix possible OOB access in PCM oss plugins · 557301cf
      Takashi Iwai authored
      commit ca0214ee upstream.
      
      The PCM OSS emulation converts and transfers the data on the fly via
      "plugins".  The data is converted over the dynamically allocated
      buffer for each plugin, and recently syzkaller caught OOB in this
      flow.
      
      Although the bisection by syzbot pointed out to the commit
      65766ee0 ("ALSA: oss: Use kvzalloc() for local buffer
      allocations"), this is merely a commit to replace vmalloc() with
      kvmalloc(), hence it can't be the cause.  The further debug action
      revealed that this happens in the case where a slave PCM doesn't
      support only the stereo channels while the OSS stream is set up for a
      mono channel.  Below is a brief explanation:
      
      At each OSS parameter change, the driver sets up the PCM hw_params
      again in snd_pcm_oss_change_params_lock().  This is also the place
      where plugins are created and local buffers are allocated.  The
      problem is that the plugins are created before the final hw_params is
      determined.  Namely, two snd_pcm_hw_param_near() calls for setting the
      period size and periods may influence on the final result of channels,
      rates, etc, too, while the current code has already created plugins
      beforehand with the premature values.  So, the plugin believes that
      channels=1, while the actual I/O is with channels=2, which makes the
      driver reading/writing over the allocated buffer size.
      
      The fix is simply to move the plugin allocation code after the final
      hw_params call.
      
      Reported-by: syzbot+d4503ae45b65c5bc1194@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>
      557301cf
    • Gustavo A. R. Silva's avatar
      ALSA: seq: oss: Fix Spectre v1 vulnerability · 8f368827
      Gustavo A. R. Silva authored
      commit c709f14f upstream.
      
      dev is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap)
      
      Fix this by sanitizing dev before using it to index dp->synths.
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f368827
    • Gustavo A. R. Silva's avatar
      ALSA: rawmidi: Fix potential Spectre v1 vulnerability · 910ffe16
      Gustavo A. R. Silva authored
      commit 2b1d9c8f upstream.
      
      info->stream is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap)
      
      Fix this by sanitizing info->stream before using it to index
      rmidi->streams.
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      910ffe16
    • Christian Lamparter's avatar
      net: dsa: qca8k: remove leftover phy accessors · af553a24
      Christian Lamparter authored
      commit 1eec7151 upstream.
      
      This belated patch implements Andrew Lunn's request of
      "remove the phy_read() and phy_write() functions."
      <https://lore.kernel.org/patchwork/comment/902734/>
      
      While seemingly harmless, this causes the switch's user
      port PHYs to get registered twice. This is because the
      DSA subsystem will create a slave mdio-bus not knowing
      that the qca8k_phy_(read|write) accessors operate on
      the external mdio-bus. So the same "bus" gets effectively
      duplicated.
      
      Cc: stable@vger.kernel.org
      Fixes: 6b93fb46 ("net-next: dsa: add new driver for qca8xxx family")
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af553a24
    • Olga Kornievskaia's avatar
      NFSv4.1 don't free interrupted slot on open · a0aa001a
      Olga Kornievskaia authored
      commit 0cb98abb upstream.
      
      Allow the async rpc task for finish and update the open state if needed,
      then free the slot. Otherwise, the async rpc unable to decode the reply.
      Signed-off-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Fixes: ae55e59d ("pnfs: Don't release the sequence slot...")
      Cc: stable@vger.kernel.org # v4.18+
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0aa001a
    • Naveen N. Rao's avatar
      powerpc: bpf: Fix generation of load/store DW instructions · fb13de8f
      Naveen N. Rao authored
      commit 86be36f6 upstream.
      
      Yauheni Kaliuta pointed out that PTR_TO_STACK store/load verifier test
      was failing on powerpc64 BE, and rightfully indicated that the PPC_LD()
      macro is not masking away the last two bits of the offset per the ISA,
      resulting in the generation of 'lwa' instruction instead of the intended
      'ld' instruction.
      
      Segher also pointed out that we can't simply mask away the last two bits
      as that will result in loading/storing from/to a memory location that
      was not intended.
      
      This patch addresses this by using ldx/stdx if the offset is not
      word-aligned. We load the offset into a temporary register (TMP_REG_2)
      and use that as the index register in a subsequent ldx/stdx. We fix
      PPC_LD() macro to mask off the last two bits, but enhance PPC_BPF_LL()
      and PPC_BPF_STL() to factor in the offset value and generate the proper
      instruction sequence. We also convert all existing users of PPC_LD() and
      PPC_STD() to use these macros. All existing uses of these macros have
      been audited to ensure that TMP_REG_2 can be clobbered.
      
      Fixes: 156d0e29 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
      Cc: stable@vger.kernel.org # v4.9+
      Reported-by: default avatarYauheni Kaliuta <yauheni.kaliuta@redhat.com>
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb13de8f
    • Kohji Okuno's avatar
      ARM: imx6q: cpuidle: fix bug that CPU might not wake up at expected time · ace6b822
      Kohji Okuno authored
      commit 91740fc8 upstream.
      
      In the current cpuidle implementation for i.MX6q, the CPU that sets
      'WAIT_UNCLOCKED' and the CPU that returns to 'WAIT_CLOCKED' are always
      the same. While the CPU that sets 'WAIT_UNCLOCKED' is in IDLE state of
      "WAIT", if the other CPU wakes up and enters IDLE state of "WFI"
      istead of "WAIT", this CPU can not wake up at expired time.
       Because, in the case of "WFI", the CPU must be waked up by the local
      timer interrupt. But, while 'WAIT_UNCLOCKED' is set, the local timer
      is stopped, when all CPUs execute "wfi" instruction. As a result, the
      local timer interrupt is not fired.
       In this situation, this CPU will wake up by IRQ different from local
      timer. (e.g. broacast timer)
      
      So, this fix changes CPU to return to 'WAIT_CLOCKED'.
      Signed-off-by: default avatarKohji Okuno <okuno.kohji@jp.panasonic.com>
      Fixes: e5f9dec8 ("ARM: imx6q: support WAIT mode using cpuidle")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ace6b822
    • Andrea Righi's avatar
      btrfs: raid56: properly unmap parity page in finish_parity_scrub() · 2b95e85f
      Andrea Righi authored
      commit 3897b6f0 upstream.
      
      Parity page is incorrectly unmapped in finish_parity_scrub(), triggering
      a reference counter bug on i386, i.e.:
      
       [ 157.662401] kernel BUG at mm/highmem.c:349!
       [ 157.666725] invalid opcode: 0000 [#1] SMP PTI
      
      The reason is that kunmap(p_page) was completely left out, so we never
      did an unmap for the p_page and the loop unmapping the rbio page was
      iterating over the wrong number of stripes: unmapping should be done
      with nr_data instead of rbio->real_stripes.
      
      Test case to reproduce the bug:
      
       - create a raid5 btrfs filesystem:
         # mkfs.btrfs -m raid5 -d raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde
      
       - mount it:
         # mount /dev/sdb /mnt
      
       - run btrfs scrub in a loop:
         # while :; do btrfs scrub start -BR /mnt; done
      
      BugLink: https://bugs.launchpad.net/bugs/1812845
      Fixes: 5a6ac9ea ("Btrfs, raid56: support parity scrub on raid56")
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarAndrea Righi <andrea.righi@canonical.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>
      2b95e85f
    • Josef Bacik's avatar
      btrfs: remove WARN_ON in log_dir_items · da04627d
      Josef Bacik authored
      commit 2cc83342 upstream.
      
      When Filipe added the recursive directory logging stuff in
      2f2ff0ee ("Btrfs: fix metadata inconsistencies after directory
      fsync") he specifically didn't take the directory i_mutex for the
      children directories that we need to log because of lockdep.  This is
      generally fine, but can lead to this WARN_ON() tripping if we happen to
      run delayed deletion's in between our first search and our second search
      of dir_item/dir_indexes for this directory.  We expect this to happen,
      so the WARN_ON() isn't necessary.  Drop the WARN_ON() and add a comment
      so we know why this case can happen.
      
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da04627d
    • Filipe Manana's avatar
      Btrfs: fix incorrect file size after shrinking truncate and fsync · dfcb397f
      Filipe Manana authored
      commit bf504110 upstream.
      
      If we do a shrinking truncate against an inode which is already present
      in the respective log tree and then rename it, as part of logging the new
      name we end up logging an inode item that reflects the old size of the
      file (the one which we previously logged) and not the new smaller size.
      The decision to preserve the size previously logged was added by commit
      1a4bcf47 ("Btrfs: fix fsync data loss after adding hard link to
      inode") in order to avoid data loss after replaying the log. However that
      decision is only needed for the case the logged inode size is smaller then
      the current size of the inode, as explained in that commit's change log.
      If the current size of the inode is smaller then the previously logged
      size, we know a shrinking truncate happened and therefore need to use
      that smaller size.
      
      Example to trigger the problem:
      
        $ mkfs.btrfs -f /dev/sdb
        $ mount /dev/sdb /mnt
      
        $ xfs_io -f -c "pwrite -S 0xab 0 8000" /mnt/foo
        $ xfs_io -c "fsync" /mnt/foo
        $ xfs_io -c "truncate 3000" /mnt/foo
      
        $ mv /mnt/foo /mnt/bar
        $ xfs_io -c "fsync" /mnt/bar
      
        <power failure>
      
        $ mount /dev/sdb /mnt
        $ od -t x1 -A d /mnt/bar
        0000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
        *
        0008000
      
      Once we rename the file, we log its name (and inode item), and because
      the inode was already logged before in the current transaction, we log it
      with a size of 8000 bytes because that is the size we previously logged
      (with the first fsync). As part of the rename, besides logging the inode,
      we do also sync the log, which is done since commit d4682ba0
      ("Btrfs: sync log after logging new name"), so the next fsync against our
      inode is effectively a no-op, since no new changes happened since the
      rename operation. Even if did not sync the log during the rename
      operation, the same problem (fize size of 8000 bytes instead of 3000
      bytes) would be visible after replaying the log if the log ended up
      getting synced to disk through some other means, such as for example by
      fsyncing some other modified file. In the example above the fsync after
      the rename operation is there just because not every filesystem may
      guarantee logging/journalling the inode (and syncing the log/journal)
      during the rename operation, for example it is needed for f2fs, but not
      for ext4 and xfs.
      
      Fix this scenario by, when logging a new name (which is triggered by
      rename and link operations), using the current size of the inode instead
      of the previously logged inode size.
      
      A test case for fstests follows soon.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202695
      CC: stable@vger.kernel.org # 4.4+
      Reported-by: default avatarSeulbae Kim <seulbae@gatech.edu>
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfcb397f
    • Michael Ellerman's avatar
      powerpc/security: Fix spectre_v2 reporting · f16b7c77
      Michael Ellerman authored
      commit 92edf8df upstream.
      
      When I updated the spectre_v2 reporting to handle software count cache
      flush I got the logic wrong when there's no software count cache
      enabled at all.
      
      The result is that on systems with the software count cache flush
      disabled we print:
      
        Mitigation: Indirect branch cache disabled, Software count cache flush
      
      Which correctly indicates that the count cache is disabled, but
      incorrectly says the software count cache flush is enabled.
      
      The root of the problem is that we are trying to handle all
      combinations of options. But we know now that we only expect to see
      the software count cache flush enabled if the other options are false.
      
      So split the two cases, which simplifies the logic and fixes the bug.
      We were also missing a space before "(hardware accelerated)".
      
      The result is we see one of:
      
        Mitigation: Indirect branch serialisation (kernel only)
        Mitigation: Indirect branch cache disabled
        Mitigation: Software count cache flush
        Mitigation: Software count cache flush (hardware accelerated)
      
      Fixes: ee13cb24 ("powerpc/64s: Add support for software count cache flush")
      Cc: stable@vger.kernel.org # v4.19+
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarMichael Neuling <mikey@neuling.org>
      Reviewed-by: default avatarDiana Craciun <diana.craciun@nxp.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f16b7c77
    • Christophe Leroy's avatar
      powerpc/fsl: Fix the flush of branch predictor. · 7b3772c0
      Christophe Leroy authored
      commit 27da8071 upstream.
      
      The commit identified below adds MC_BTB_FLUSH macro only when
      CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
      on some configs (seen several times with kisskb randconfig_defconfig)
      
      arch/powerpc/kernel/exceptions-64e.S:576: Error: Unrecognized opcode: `mc_btb_flush'
      make[3]: *** [scripts/Makefile.build:367: arch/powerpc/kernel/exceptions-64e.o] Error 1
      make[2]: *** [scripts/Makefile.build:492: arch/powerpc/kernel] Error 2
      make[1]: *** [Makefile:1043: arch/powerpc] Error 2
      make: *** [Makefile:152: sub-make] Error 2
      
      This patch adds a blank definition of MC_BTB_FLUSH for other cases.
      
      Fixes: 10c5e83a ("powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)")
      Cc: Diana Craciun <diana.craciun@nxp.com>
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: default avatarDaniel Axtens <dja@axtens.net>
      Reviewed-by: default avatarDiana Craciun <diana.craciun@nxp.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b3772c0