1. 11 Jun, 2019 40 commits
    • Alan Stern's avatar
      USB: Fix slab-out-of-bounds write in usb_get_bos_descriptor · 018b7ea9
      Alan Stern authored
      commit a03ff54460817c76105f81f3aa8ef655759ccc9a upstream.
      
      The syzkaller USB fuzzer found a slab-out-of-bounds write bug in the
      USB core, caused by a failure to check the actual size of a BOS
      descriptor.  This patch adds a check to make sure the descriptor is at
      least as large as it is supposed to be, so that the code doesn't
      inadvertently access memory beyond the end of the allocated region
      when assigning to dev->bos->desc->bNumDeviceCaps later on.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+71f1e64501a309fcc012@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      018b7ea9
    • Carsten Schmid's avatar
      usb: xhci: avoid null pointer deref when bos field is NULL · f5e1ec93
      Carsten Schmid authored
      commit 7aa1bb2ffd84d6b9b5f546b079bb15cd0ab6e76e upstream.
      
      With defective USB sticks we see the following error happen:
      usb 1-3: new high-speed USB device number 6 using xhci_hcd
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: new high-speed USB device number 7 using xhci_hcd
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: unable to get BOS descriptor set
      usb 1-3: New USB device found, idVendor=0781, idProduct=5581
      usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      ...
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      
      This comes from the following place:
      [ 1660.215380] IP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
      [ 1660.222092] PGD 0 P4D 0
      [ 1660.224918] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [ 1660.425520] CPU: 1 PID: 38 Comm: kworker/1:1 Tainted: P     U  W  O    4.14.67-apl #1
      [ 1660.434277] Workqueue: usb_hub_wq hub_event [usbcore]
      [ 1660.439918] task: ffffa295b6ae4c80 task.stack: ffffad4580150000
      [ 1660.446532] RIP: 0010:xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
      [ 1660.453821] RSP: 0018:ffffad4580153c70 EFLAGS: 00010046
      [ 1660.459655] RAX: 0000000000000000 RBX: ffffa295b4d7c000 RCX: 0000000000000002
      [ 1660.467625] RDX: 0000000000000002 RSI: ffffffff984a55b2 RDI: ffffffff984a55b2
      [ 1660.475586] RBP: ffffad4580153cc8 R08: 0000000000d6520a R09: 0000000000000001
      [ 1660.483556] R10: ffffad4580a004a0 R11: 0000000000000286 R12: ffffa295b4d7c000
      [ 1660.491525] R13: 0000000000010648 R14: ffffa295a84e1800 R15: 0000000000000000
      [ 1660.499494] FS:  0000000000000000(0000) GS:ffffa295bfc80000(0000) knlGS:0000000000000000
      [ 1660.508530] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1660.514947] CR2: 0000000000000008 CR3: 000000025a114000 CR4: 00000000003406a0
      [ 1660.522917] Call Trace:
      [ 1660.525657]  usb_set_usb2_hardware_lpm+0x3d/0x70 [usbcore]
      [ 1660.531792]  usb_disable_device+0x242/0x260 [usbcore]
      [ 1660.537439]  usb_disconnect+0xc1/0x2b0 [usbcore]
      [ 1660.542600]  hub_event+0x596/0x18f0 [usbcore]
      [ 1660.547467]  ? trace_preempt_on+0xdf/0x100
      [ 1660.552040]  ? process_one_work+0x1c1/0x410
      [ 1660.556708]  process_one_work+0x1d2/0x410
      [ 1660.561184]  ? preempt_count_add.part.3+0x21/0x60
      [ 1660.566436]  worker_thread+0x2d/0x3f0
      [ 1660.570522]  kthread+0x122/0x140
      [ 1660.574123]  ? process_one_work+0x410/0x410
      [ 1660.578792]  ? kthread_create_on_node+0x60/0x60
      [ 1660.583849]  ret_from_fork+0x3a/0x50
      [ 1660.587839] Code: 00 49 89 c3 49 8b 84 24 50 16 00 00 8d 4a ff 48 8d 04 c8 48 89 ca 4c 8b 10 45 8b 6a 04 48 8b 00 48 89 45 c0 49 8b 86 80 03 00 00 <48> 8b 40 08 8b 40 03 0f 1f 44 00 00 45 85 ff 0f 84 81 01 00 00
      [ 1660.608980] RIP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd] RSP: ffffad4580153c70
      [ 1660.617921] CR2: 0000000000000008
      
      Tracking this down shows that udev->bos is NULL in the following code:
      (xhci.c, in xhci_set_usb2_hardware_lpm)
      	field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);  <<<<<<< here
      
      	xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
      			enable ? "enable" : "disable", port_num + 1);
      
      	if (enable) {
      		/* Host supports BESL timeout instead of HIRD */
      		if (udev->usb2_hw_lpm_besl_capable) {
      			/* if device doesn't have a preferred BESL value use a
      			 * default one which works with mixed HIRD and BESL
      			 * systems. See XHCI_DEFAULT_BESL definition in xhci.h
      			 */
      			if ((field & USB_BESL_SUPPORT) &&
      			    (field & USB_BESL_BASELINE_VALID))
      				hird = USB_GET_BESL_BASELINE(field);
      			else
      				hird = udev->l1_params.besl;
      
      The failing case is when disabling LPM. So it is sufficient to avoid
      access to udev->bos by moving the instruction into the "enable" clause.
      
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarCarsten Schmid <carsten_schmid@mentor.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5e1ec93
    • Andrey Smirnov's avatar
      xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic() · 017e6726
      Andrey Smirnov authored
      commit f7fac17ca925faa03fc5eb854c081a24075f8bad upstream.
      
      Xhci_handshake() implements the algorithm already captured by
      readl_poll_timeout_atomic(). Convert the former to use the latter to
      avoid repetition.
      
      Turned out this patch also fixes a bug on the AMD Stoneyridge platform
      where usleep(1) sometimes takes over 10ms.
      This means a 5 second timeout can easily take over 15 seconds which will
      trigger the watchdog and reboot the system.
      
      [Add info about patch fixing a bug to commit message -Mathias]
      Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Tested-by: default avatarRaul E Rangel <rrangel@chromium.org>
      Reviewed-by: default avatarRaul E Rangel <rrangel@chromium.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      017e6726
    • Rasmus Villemoes's avatar
      include/linux/bitops.h: sanitize rotate primitives · ec70e2c1
      Rasmus Villemoes authored
      commit ef4d6f6b275c498f8e5626c99dbeefdc5027f843 upstream.
      
      The ror32 implementation (word >> shift) | (word << (32 - shift) has
      undefined behaviour if shift is outside the [1, 31] range.  Similarly
      for the 64 bit variants.  Most callers pass a compile-time constant
      (naturally in that range), but there's an UBSAN report that these may
      actually be called with a shift count of 0.
      
      Instead of special-casing that, we can make them DTRT for all values of
      shift while also avoiding UB.  For some reason, this was already partly
      done for rol32 (which was well-defined for [0, 31]).  gcc 8 recognizes
      these patterns as rotates, so for example
      
        __u32 rol32(__u32 word, unsigned int shift)
        {
      	return (word << (shift & 31)) | (word >> ((-shift) & 31));
        }
      
      compiles to
      
      0000000000000020 <rol32>:
        20:   89 f8                   mov    %edi,%eax
        22:   89 f1                   mov    %esi,%ecx
        24:   d3 c0                   rol    %cl,%eax
        26:   c3                      retq
      
      Older compilers unfortunately do not do as well, but this only affects
      the small minority of users that don't pass constants.
      
      Due to integer promotions, ro[lr]8 were already well-defined for shifts
      in [0, 8], and ro[lr]16 were mostly well-defined for shifts in [0, 16]
      (only mostly - u16 gets promoted to _signed_ int, so if bit 15 is set,
      word << 16 is undefined).  For consistency, update those as well.
      
      Link: http://lkml.kernel.org/r/20190410211906.2190-1-linux@rasmusvillemoes.dkSigned-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reported-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Tested-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Vadim Pasternak <vadimp@mellanox.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec70e2c1
    • James Clarke's avatar
      sparc64: Fix regression in non-hypervisor TLB flush xcall · fbbc4fe0
      James Clarke authored
      commit d3c976c14ad8af421134c428b0a89ff8dd3bd8f8 upstream.
      
      Previously, %g2 would end up with the value PAGE_SIZE, but after the
      commit mentioned below it ends up with the value 1 due to being reused
      for a different purpose. We need it to be PAGE_SIZE as we use it to step
      through pages in our demap loop, otherwise we set different flags in the
      low 12 bits of the address written to, thereby doing things other than a
      nucleus page flush.
      
      Fixes: a74ad5e6 ("sparc64: Handle extremely large kernel TLB range flushes more gracefully.")
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarJames Clarke <jrtc27@jrtc27.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbbc4fe0
    • Junwei Hu's avatar
      tipc: fix modprobe tipc failed after switch order of device registration -v2 · 5bce46ed
      Junwei Hu authored
      commit 526f5b851a96566803ee4bee60d0a34df56c77f8 upstream.
      
      Error message printed:
      modprobe: ERROR: could not insert 'tipc': Address family not
      supported by protocol.
      when modprobe tipc after the following patch: switch order of
      device registration, commit 7e27e8d6130c
      ("tipc: switch order of device registration to fix a crash")
      
      Because sock_create_kern(net, AF_TIPC, ...) called by
      tipc_topsrv_create_listener() in the initialization process
      of tipc_init_net(), so tipc_socket_init() must be execute before that.
      Meanwhile, tipc_net_id need to be initialized when sock_create()
      called, and tipc_socket_init() is no need to be called for each namespace.
      
      I add a variable tipc_topsrv_net_ops, and split the
      register_pernet_subsys() of tipc into two parts, and split
      tipc_socket_init() with initialization of pernet params.
      
      By the way, I fixed resources rollback error when tipc_bcast_init()
      failed in tipc_init_net().
      
      Fixes: 7e27e8d6130c ("tipc: switch order of device registration to fix a crash")
      Signed-off-by: default avatarJunwei Hu <hujunwei4@huawei.com>
      Reported-by: default avatarWang Wang <wangwang2@huawei.com>
      Reported-by: syzbot+1e8114b61079bfe9cbc5@syzkaller.appspotmail.com
      Reviewed-by: default avatarKang Zhou <zhoukang7@huawei.com>
      Reviewed-by: default avatarSuanming Mou <mousuanming@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5bce46ed
    • David S. Miller's avatar
      Revert "tipc: fix modprobe tipc failed after switch order of device registration" · 416d252b
      David S. Miller authored
      commit 5593530e56943182ebb6d81eca8a3be6db6dbba4 upstream.
      
      This reverts commit 532b0f7ece4cb2ffd24dc723ddf55242d1188e5e.
      
      More revisions coming up.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      416d252b
    • Konrad Rzeszutek Wilk's avatar
      xen/pciback: Don't disable PCI_COMMAND on PCI device reset. · f1613a9e
      Konrad Rzeszutek Wilk authored
      commit 7681f31ec9cdacab4fd10570be924f2cef6669ba upstream.
      
      There is no need for this at all. Worst it means that if
      the guest tries to write to BARs it could lead (on certain
      platforms) to PCI SERR errors.
      
      Please note that with af6fc858
      "xen-pciback: limit guest control of command register"
      a guest is still allowed to enable those control bits (safely), but
      is not allowed to disable them and that therefore a well behaved
      frontend which enables things before using them will still
      function correctly.
      
      This is done via an write to the configuration register 0x4 which
      triggers on the backend side:
      command_write
        \- pci_enable_device
           \- pci_enable_device_flags
              \- do_pci_enable_device
                 \- pcibios_enable_device
                    \-pci_enable_resourcess
                      [which enables the PCI_COMMAND_MEMORY|PCI_COMMAND_IO]
      
      However guests (and drivers) which don't do this could cause
      problems, including the security issues which XSA-120 sought
      to address.
      Reported-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1613a9e
    • Daniel Axtens's avatar
      crypto: vmx - ghash: do nosimd fallback manually · 383687e1
      Daniel Axtens authored
      commit 357d065a44cdd77ed5ff35155a989f2a763e96ef upstream.
      
      VMX ghash was using a fallback that did not support interleaving simd
      and nosimd operations, leading to failures in the extended test suite.
      
      If I understood correctly, Eric's suggestion was to use the same
      data format that the generic code uses, allowing us to call into it
      with the same contexts. I wasn't able to get that to work - I think
      there's a very different key structure and data layout being used.
      
      So instead steal the arm64 approach and perform the fallback
      operations directly if required.
      
      Fixes: cc333cd6 ("crypto: vmx - Adding GHASH routines for VMX module")
      Cc: stable@vger.kernel.org # v4.1+
      Reported-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Tested-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      383687e1
    • Antoine Tenart's avatar
      net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue value · 61ba8e9f
      Antoine Tenart authored
      [ Upstream commit 21808437214637952b61beaba6034d97880fbeb3 ]
      
      MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but
      the current code is passing the global tx queue offset, so it ends
      up writing to unknown registers (between 0x8280 and 0x82fc, which
      seemed to be unused by the hardware). This fixes the issue by using
      the logical queue id instead.
      
      Fixes: 3f518509 ("ethernet: Add new driver for Marvell Armada 375 network unit")
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61ba8e9f
    • Michael Chan's avatar
      bnxt_en: Fix aggregation buffer leak under OOM condition. · 1d33a3eb
      Michael Chan authored
      [ Upstream commit 296d5b54163964b7ae536b8b57dfbd21d4e868e1 ]
      
      For every RX packet, the driver replenishes all buffers used for that
      packet and puts them back into the RX ring and RX aggregation ring.
      In one code path where the RX packet has one RX buffer and one or more
      aggregation buffers, we missed recycling the aggregation buffer(s) if
      we are unable to allocate a new SKB buffer.  This leads to the
      aggregation ring slowly running out of buffers over time.  Fix it
      by properly recycling the aggregation buffers.
      
      Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.")
      Reported-by: default avatarRakesh Hemnani <rhemnani@fb.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d33a3eb
    • Chris Packham's avatar
      tipc: Avoid copying bytes beyond the supplied data · 7d423301
      Chris Packham authored
      TLV_SET is called with a data pointer and a len parameter that tells us
      how many bytes are pointed to by data. When invoking memcpy() we need
      to careful to only copy len bytes.
      
      Previously we would copy TLV_LENGTH(len) bytes which would copy an extra
      4 bytes past the end of the data pointer which newer GCC versions
      complain about.
      
       In file included from test.c:17:
       In function 'TLV_SET',
           inlined from 'test' at test.c:186:5:
       /usr/include/linux/tipc_config.h:317:3:
       warning: 'memcpy' forming offset [33, 36] is out of the bounds [0, 32]
       of object 'bearer_name' with type 'char[32]' [-Warray-bounds]
           memcpy(TLV_DATA(tlv_ptr), data, tlv_len);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       test.c: In function 'test':
       test.c::161:10: note:
       'bearer_name' declared here
           char bearer_name[TIPC_MAX_BEARER_NAME];
                ^~~~~~~~~~~
      
      We still want to ensure any padding bytes at the end are initialised, do
      this with a explicit memset() rather than copy bytes past the end of
      data. Apply the same logic to TCM_SET.
      Signed-off-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d423301
    • Kloetzke Jan's avatar
      usbnet: fix kernel crash after disconnect · 332bff9d
      Kloetzke Jan authored
      [ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
      
      When disconnecting cdc_ncm the kernel sporadically crashes shortly
      after the disconnect:
      
        [   57.868812] Unable to handle kernel NULL pointer dereference at virtual address 00000000
        ...
        [   58.006653] PC is at 0x0
        [   58.009202] LR is at call_timer_fn+0xec/0x1b4
        [   58.013567] pc : [<0000000000000000>] lr : [<ffffff80080f5130>] pstate: 00000145
        [   58.020976] sp : ffffff8008003da0
        [   58.024295] x29: ffffff8008003da0 x28: 0000000000000001
        [   58.029618] x27: 000000000000000a x26: 0000000000000100
        [   58.034941] x25: 0000000000000000 x24: ffffff8008003e68
        [   58.040263] x23: 0000000000000000 x22: 0000000000000000
        [   58.045587] x21: 0000000000000000 x20: ffffffc68fac1808
        [   58.050910] x19: 0000000000000100 x18: 0000000000000000
        [   58.056232] x17: 0000007f885aff8c x16: 0000007f883a9f10
        [   58.061556] x15: 0000000000000001 x14: 000000000000006e
        [   58.066878] x13: 0000000000000000 x12: 00000000000000ba
        [   58.072201] x11: ffffffc69ff1db30 x10: 0000000000000020
        [   58.077524] x9 : 8000100008001000 x8 : 0000000000000001
        [   58.082847] x7 : 0000000000000800 x6 : ffffff8008003e70
        [   58.088169] x5 : ffffffc69ff17a28 x4 : 00000000ffff138b
        [   58.093492] x3 : 0000000000000000 x2 : 0000000000000000
        [   58.098814] x1 : 0000000000000000 x0 : 0000000000000000
        ...
        [   58.205800] [<          (null)>]           (null)
        [   58.210521] [<ffffff80080f5298>] expire_timers+0xa0/0x14c
        [   58.215937] [<ffffff80080f542c>] run_timer_softirq+0xe8/0x128
        [   58.221702] [<ffffff8008081120>] __do_softirq+0x298/0x348
        [   58.227118] [<ffffff80080a6304>] irq_exit+0x74/0xbc
        [   58.232009] [<ffffff80080e17dc>] __handle_domain_irq+0x78/0xac
        [   58.237857] [<ffffff8008080cf4>] gic_handle_irq+0x80/0xac
        ...
      
      The crash happens roughly 125..130ms after the disconnect. This
      correlates with the 'delay' timer that is started on certain USB tx/rx
      errors in the URB completion handler.
      
      The problem is a race of usbnet_stop() with usbnet_start_xmit(). In
      usbnet_stop() we call usbnet_terminate_urbs() to cancel all URBs in
      flight. This only makes sense if no new URBs are submitted
      concurrently, though. But the usbnet_start_xmit() can run at the same
      time on another CPU which almost unconditionally submits an URB. The
      error callback of the new URB will then schedule the timer after it was
      already stopped.
      
      The fix adds a check if the tx queue is stopped after the tx list lock
      has been taken. This should reliably prevent the submission of new URBs
      while usbnet_terminate_urbs() does its job. The same thing is done on
      the rx side even though it might be safe due to other flags that are
      checked there.
      Signed-off-by: default avatarJan Klötzke <Jan.Kloetzke@preh.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      332bff9d
    • Jisheng Zhang's avatar
      net: stmmac: fix reset gpio free missing · 16ffb5f7
      Jisheng Zhang authored
      [ Upstream commit 49ce881c0d4c4a7a35358d9dccd5f26d0e56fc61 ]
      
      Commit 984203ce ("net: stmmac: mdio: remove reset gpio free")
      removed the reset gpio free, when the driver is unbinded or rmmod,
      we miss the gpio free.
      
      This patch uses managed API to request the reset gpio, so that the
      gpio could be freed properly.
      
      Fixes: 984203ce ("net: stmmac: mdio: remove reset gpio free")
      Signed-off-by: default avatarJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16ffb5f7
    • Eric Dumazet's avatar
      net-gro: fix use-after-free read in napi_gro_frags() · 4f9c73aa
      Eric Dumazet authored
      [ Upstream commit a4270d6795b0580287453ea55974d948393e66ef ]
      
      If a network driver provides to napi_gro_frags() an
      skb with a page fragment of exactly 14 bytes, the call
      to gro_pull_from_frag0() will 'consume' the fragment
      by calling skb_frag_unref(skb, 0), and the page might
      be freed and reused.
      
      Reading eth->h_proto at the end of napi_frags_skb() might
      read mangled data, or crash under specific debugging features.
      
      BUG: KASAN: use-after-free in napi_frags_skb net/core/dev.c:5833 [inline]
      BUG: KASAN: use-after-free in napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
      Read of size 2 at addr ffff88809366840c by task syz-executor599/8957
      
      CPU: 1 PID: 8957 Comm: syz-executor599 Not tainted 5.2.0-rc1+ #32
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142
       napi_frags_skb net/core/dev.c:5833 [inline]
       napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
       tun_get_user+0x2f3c/0x3ff0 drivers/net/tun.c:1991
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037
       call_write_iter include/linux/fs.h:1872 [inline]
       do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693
       do_iter_write fs/read_write.c:970 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:951
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
       do_writev+0x15b/0x330 fs/read_write.c:1058
      
      Fixes: a50e233c ("net-gro: restore frag0 optimization")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f9c73aa
    • Eric Dumazet's avatar
      llc: fix skb leak in llc_build_and_send_ui_pkt() · 5cbaa135
      Eric Dumazet authored
      [ Upstream commit 8fb44d60d4142cd2a440620cd291d346e23c131e ]
      
      If llc_mac_hdr_init() returns an error, we must drop the skb
      since no llc_build_and_send_ui_pkt() caller will take care of this.
      
      BUG: memory leak
      unreferenced object 0xffff8881202b6800 (size 2048):
        comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.590s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
        backtrace:
          [<00000000e25b5abe>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<00000000e25b5abe>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<00000000e25b5abe>] slab_alloc mm/slab.c:3326 [inline]
          [<00000000e25b5abe>] __do_kmalloc mm/slab.c:3658 [inline]
          [<00000000e25b5abe>] __kmalloc+0x161/0x2c0 mm/slab.c:3669
          [<00000000a1ae188a>] kmalloc include/linux/slab.h:552 [inline]
          [<00000000a1ae188a>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1608
          [<00000000ded25bbe>] sk_alloc+0x35/0x2f0 net/core/sock.c:1662
          [<000000002ecae075>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
          [<00000000551f7c47>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173
          [<0000000029027f0e>] __sock_create+0x164/0x250 net/socket.c:1430
          [<000000008bdec225>] sock_create net/socket.c:1481 [inline]
          [<000000008bdec225>] __sys_socket+0x69/0x110 net/socket.c:1523
          [<00000000b6439228>] __do_sys_socket net/socket.c:1532 [inline]
          [<00000000b6439228>] __se_sys_socket net/socket.c:1530 [inline]
          [<00000000b6439228>] __x64_sys_socket+0x1e/0x30 net/socket.c:1530
          [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      BUG: memory leak
      unreferenced object 0xffff88811d750d00 (size 224):
        comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.600s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 f0 0c 24 81 88 ff ff 00 68 2b 20 81 88 ff ff  ...$.....h+ ....
        backtrace:
          [<0000000053026172>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
          [<0000000053026172>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<0000000053026172>] slab_alloc_node mm/slab.c:3269 [inline]
          [<0000000053026172>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
          [<00000000fa8f3c30>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
          [<00000000d96fdafb>] alloc_skb include/linux/skbuff.h:1058 [inline]
          [<00000000d96fdafb>] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327
          [<000000000a34a2e7>] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225
          [<00000000ee39999b>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242
          [<00000000e034d810>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
          [<00000000c0bc8445>] sock_sendmsg_nosec net/socket.c:652 [inline]
          [<00000000c0bc8445>] sock_sendmsg+0x54/0x70 net/socket.c:671
          [<000000003b687167>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
          [<00000000922d78d9>] __do_sys_sendto net/socket.c:1976 [inline]
          [<00000000922d78d9>] __se_sys_sendto net/socket.c:1972 [inline]
          [<00000000922d78d9>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972
          [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5cbaa135
    • Mike Manning's avatar
      ipv6: Consider sk_bound_dev_if when binding a raw socket to an address · 36a72220
      Mike Manning authored
      [ Upstream commit 72f7cfab6f93a8ea825fab8ccfb016d064269f7f ]
      
      IPv6 does not consider if the socket is bound to a device when binding
      to an address. The result is that a socket can be bound to eth0 and
      then bound to the address of eth1. If the device is a VRF, the result
      is that a socket can only be bound to an address in the default VRF.
      
      Resolve by considering the device if sk_bound_dev_if is set.
      Signed-off-by: default avatarMike Manning <mmanning@vyatta.att-mail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Tested-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36a72220
    • Arnd Bergmann's avatar
      ASoC: davinci-mcasp: Fix clang warning without CONFIG_PM · 9fbf1ac5
      Arnd Bergmann authored
      [ Upstream commit 8ca5104715cfd14254ea5aecc390ae583b707607 ]
      
      Building with clang shows a variable that is only used by the
      suspend/resume functions but defined outside of their #ifdef block:
      
      sound/soc/ti/davinci-mcasp.c:48:12: error: variable 'context_regs' is not needed and will not be emitted
      
      We commonly fix these by marking the PM functions as __maybe_unused,
      but here that would grow the davinci_mcasp structure, so instead
      add another #ifdef here.
      
      Fixes: 1cc0c054 ("ASoC: davinci-mcasp: Convert the context save/restore to use array")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9fbf1ac5
    • Chris Lesiak's avatar
      spi: Fix zero length xfer bug · 0984cb76
      Chris Lesiak authored
      [ Upstream commit 5442dcaa0d90fc376bdfc179a018931a8f43dea4 ]
      
      This fixes a bug for messages containing both zero length and
      unidirectional xfers.
      
      The function spi_map_msg will allocate dummy tx and/or rx buffers
      for use with unidirectional transfers when the hardware can only do
      a bidirectional transfer.  That dummy buffer will be used in place
      of a NULL buffer even when the xfer length is 0.
      
      Then in the function __spi_map_msg, if he hardware can dma,
      the zero length xfer will have spi_map_buf called on the dummy
      buffer.
      
      Eventually, __sg_alloc_table is called and returns -EINVAL
      because nents == 0.
      
      This fix prevents the error by not using the dummy buffer when
      the xfer length is zero.
      Signed-off-by: default avatarChris Lesiak <chris.lesiak@licor.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0984cb76
    • Geert Uytterhoeven's avatar
      spi: rspi: Fix sequencer reset during initialization · 854415f3
      Geert Uytterhoeven authored
      [ Upstream commit 26843bb128590edd7eba1ad7ce22e4b9f1066ce3 ]
      
      While the sequencer is reset after each SPI message since commit
      880c6d11 ("spi: rspi: Add support for Quad and Dual SPI
      Transfers on QSPI"), it was never reset for the first message, thus
      relying on reset state or bootloader settings.
      
      Fix this by initializing it explicitly during configuration.
      
      Fixes: 0b2182dd ("spi: add support for Renesas RSPI")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      854415f3
    • Aditya Pakki's avatar
      spi : spi-topcliff-pch: Fix to handle empty DMA buffers · c9274518
      Aditya Pakki authored
      [ Upstream commit f37d8e67f39e6d3eaf4cc5471e8a3d21209843c6 ]
      
      pch_alloc_dma_buf allocated tx, rx DMA buffers which can fail. Further,
      these buffers are used without a check. The patch checks for these
      failures and sends the error upstream.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c9274518
    • James Smart's avatar
      scsi: lpfc: Fix SLI3 commands being issued on SLI4 devices · 445c0740
      James Smart authored
      [ Upstream commit c95a3b4b0fb8d351e2329a96f87c4fc96a149505 ]
      
      During debug, it was seen that the driver is issuing commands specific to
      SLI3 on SLI4 devices. Although the adapter correctly rejected the command,
      this should not be done.
      
      Revise the code to stop sending these commands on a SLI4 adapter.
      Signed-off-by: default avatarDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: default avatarJames Smart <jsmart2021@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      445c0740
    • Arnd Bergmann's avatar
      media: saa7146: avoid high stack usage with clang · 3a5d1133
      Arnd Bergmann authored
      [ Upstream commit 03aa4f191a36f33fce015387f84efa0eee94408e ]
      
      Two saa7146/hexium files contain a construct that causes a warning
      when built with clang:
      
      drivers/media/pci/saa7146/hexium_orion.c:210:12: error: stack frame size of 2272 bytes in function 'hexium_probe'
            [-Werror,-Wframe-larger-than=]
      static int hexium_probe(struct saa7146_dev *dev)
                 ^
      drivers/media/pci/saa7146/hexium_gemini.c:257:12: error: stack frame size of 2304 bytes in function 'hexium_attach'
            [-Werror,-Wframe-larger-than=]
      static int hexium_attach(struct saa7146_dev *dev, struct saa7146_pci_extension_data *info)
                 ^
      
      This one happens regardless of KASAN, and the problem is that a
      constructor to initialize a dynamically allocated structure leads
      to a copy of that structure on the stack, whereas gcc initializes
      it in place.
      
      Link: https://bugs.llvm.org/show_bug.cgi?id=40776Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      [hverkuil-cisco@xs4all.nl: fix checkpatch warnings]
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3a5d1133
    • Arnd Bergmann's avatar
      media: go7007: avoid clang frame overflow warning with KASAN · 5a96cf10
      Arnd Bergmann authored
      [ Upstream commit ed713a4a1367aca5c0f2f329579465db00c17995 ]
      
      clang-8 warns about one function here when KASAN is enabled, even
      without the 'asan-stack' option:
      
      drivers/media/usb/go7007/go7007-fw.c:1551:5: warning: stack frame size of 2656 bytes in function
      
      I have reported this issue in the llvm bugzilla, but to make
      it work with the clang-8 release, a small annotation is still
      needed.
      
      Link: https://bugs.llvm.org/show_bug.cgi?id=38809Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      [hverkuil-cisco@xs4all.nl: fix checkpatch warning]
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5a96cf10
    • James Hutchinson's avatar
      media: m88ds3103: serialize reset messages in m88ds3103_set_frontend · 0e9f0805
      James Hutchinson authored
      [ Upstream commit 981fbe3da20a6f35f17977453bce7dfc1664d74f ]
      
      Ref: https://bugzilla.kernel.org/show_bug.cgi?id=199323
      
      Users are experiencing problems with the DVBSky S960/S960C USB devices
      since the following commit:
      
      9d659ae1: ("locking/mutex: Add lock handoff to avoid starvation")
      
      The device malfunctions after running for an indeterminable period of
      time, and the problem can only be cleared by rebooting the machine.
      
      It is possible to encourage the problem to surface by blocking the
      signal to the LNB.
      
      Further debugging revealed the cause of the problem.
      
      In the following capture:
      - thread #1325 is running m88ds3103_set_frontend
      - thread #42 is running ts2020_stat_work
      
      a> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 80
         [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 08
         [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 68 3f
         [42] usb 1-1: dvb_usb_v2_generic_io: <<< 08 ff
         [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11
         [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07
         [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 3d
         [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff
      b> [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 07 00
         [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07
         [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11
         [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07
         [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 21
         [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff
         [42] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11
         [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07
         [42] usb 1-1: dvb_usb_v2_generic_io: >>> 09 01 01 60 66
         [42] usb 1-1: dvb_usb_v2_generic_io: <<< 07 ff
         [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 68 02 03 11
         [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07
         [1325] usb 1-1: dvb_usb_v2_generic_io: >>> 08 60 02 10 0b
         [1325] usb 1-1: dvb_usb_v2_generic_io: <<< 07
      
      Two i2c messages are sent to perform a reset in m88ds3103_set_frontend:
      
        a. 0x07, 0x80
        b. 0x07, 0x00
      
      However, as shown in the capture, the regmap mutex is being handed over
      to another thread (ts2020_stat_work) in between these two messages.
      
      >From here, the device responds to every i2c message with an 07 message,
      and will only return to normal operation following a power cycle.
      
      Use regmap_multi_reg_write to group the two reset messages, ensuring
      both are processed before the regmap mutex is unlocked.
      Signed-off-by: default avatarJames Hutchinson <jahutchinson99@googlemail.com>
      Reviewed-by: default avatarAntti Palosaari <crope@iki.fi>
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0e9f0805
    • Arnd Bergmann's avatar
      scsi: qla4xxx: avoid freeing unallocated dma memory · 9effa389
      Arnd Bergmann authored
      [ Upstream commit 608f729c31d4caf52216ea00d20092a80959256d ]
      
      Clang -Wuninitialized notices that on is_qla40XX we never allocate any DMA
      memory in get_fw_boot_info() but attempt to free it anyway:
      
      drivers/scsi/qla4xxx/ql4_os.c:5915:7: error: variable 'buf_dma' is used uninitialized whenever 'if' condition is false
            [-Werror,-Wsometimes-uninitialized]
                      if (!(val & 0x07)) {
                          ^~~~~~~~~~~~~
      drivers/scsi/qla4xxx/ql4_os.c:5985:47: note: uninitialized use occurs here
              dma_free_coherent(&ha->pdev->dev, size, buf, buf_dma);
                                                           ^~~~~~~
      drivers/scsi/qla4xxx/ql4_os.c:5915:3: note: remove the 'if' if its condition is always true
                      if (!(val & 0x07)) {
                      ^~~~~~~~~~~~~~~~~~~
      drivers/scsi/qla4xxx/ql4_os.c:5885:20: note: initialize the variable 'buf_dma' to silence this warning
              dma_addr_t buf_dma;
                                ^
                                 = 0
      
      Skip the call to dma_free_coherent() here.
      
      Fixes: 2a991c21 ("[SCSI] qla4xxx: Boot from SAN support for open-iscsi")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9effa389
    • Tony Lindgren's avatar
      usb: core: Add PM runtime calls to usb_hcd_platform_shutdown · 95f0bb0a
      Tony Lindgren authored
      [ Upstream commit 8ead7e817224d7832fe51a19783cb8fcadc79467 ]
      
      If ohci-platform is runtime suspended, we can currently get an "imprecise
      external abort" on reboot with ohci-platform loaded when PM runtime
      is implemented for the SoC.
      
      Let's fix this by adding PM runtime support to usb_hcd_platform_shutdown.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      95f0bb0a
    • Paul E. McKenney's avatar
      rcutorture: Fix cleanup path for invalid torture_type strings · 1909121a
      Paul E. McKenney authored
      [ Upstream commit b813afae7ab6a5e91b4e16cc567331d9c2ae1f04 ]
      
      If the specified rcutorture.torture_type is not in the rcu_torture_init()
      function's torture_ops[] array, rcutorture prints some console messages
      and then invokes rcu_torture_cleanup() to set state so that a future
      torture test can run.  However, rcu_torture_cleanup() also attempts to
      end the test that didn't actually start, and in doing so relies on the
      value of cur_ops, a value that is not particularly relevant in this case.
      This can result in confusing output or even follow-on failures due to
      attempts to use facilities that have not been properly initialized.
      
      This commit therefore sets the value of cur_ops to NULL in this case
      and inserts a check near the beginning of rcu_torture_cleanup(),
      thus avoiding relying on an irrelevant cur_ops value.
      Reported-by: default avatarkernel test robot <rong.a.chen@intel.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.ibm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1909121a
    • Kangjie Lu's avatar
      tty: ipwireless: fix missing checks for ioremap · 1081d04a
      Kangjie Lu authored
      [ Upstream commit 1bbb1c318cd8a3a39e8c3e2e83d5e90542d6c3e3 ]
      
      ipw->attr_memory and ipw->common_memory are assigned with the
      return value of ioremap. ioremap may fail, but no checks
      are enforced. The fix inserts the checks to avoid potential
      NULL pointer dereferences.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1081d04a
    • Pankaj Gupta's avatar
      virtio_console: initialize vtermno value for ports · c05b2ed7
      Pankaj Gupta authored
      [ Upstream commit 4b0a2c5ff7215206ea6135a405f17c5f6fca7d00 ]
      
      For regular serial ports we do not initialize value of vtermno
      variable. A garbage value is assigned for non console ports.
      The value can be observed as a random integer with [1].
      
      [1] vim /sys/kernel/debug/virtio-ports/vport*p*
      
      This patch initialize the value of vtermno for console serial
      ports to '1' and regular serial ports are initiaized to '0'.
      
      Reported-by: siliu@redhat.com
      Signed-off-by: default avatarPankaj Gupta <pagupta@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c05b2ed7
    • Dan Carpenter's avatar
      media: wl128x: prevent two potential buffer overflows · 348ec7b9
      Dan Carpenter authored
      [ Upstream commit 9c2ccc324b3a6cbc865ab8b3e1a09e93d3c8ade9 ]
      
      Smatch marks skb->data as untrusted so it warns that "evt_hdr->dlen"
      can copy up to 255 bytes and we only have room for two bytes.  Even
      if this comes from the firmware and we trust it, the new policy
      generally is just to fix it as kernel hardenning.
      
      I can't test this code so I tried to be very conservative.  I considered
      not allowing "evt_hdr->dlen == 1" because it doesn't initialize the
      whole variable but in the end I decided to allow it and manually
      initialized "asic_id" and "asic_ver" to zero.
      
      Fixes: e8454ff7 ("[media] drivers:media:radio: wl128x: FM Driver Common sources")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      348ec7b9
    • Sowjanya Komatineni's avatar
      spi: tegra114: reset controller on probe · 557ae685
      Sowjanya Komatineni authored
      [ Upstream commit 019194933339b3e9b486639c8cb3692020844d65 ]
      
      Fixes: SPI driver can be built as module so perform SPI controller reset
      on probe to make sure it is in valid state before initiating transfer.
      Signed-off-by: default avatarSowjanya Komatineni <skomatineni@nvidia.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      557ae685
    • Gustavo A. R. Silva's avatar
      cxgb3/l2t: Fix undefined behaviour · 5e75d5e2
      Gustavo A. R. Silva authored
      [ Upstream commit 76497732932f15e7323dc805e8ea8dc11bb587cf ]
      
      The use of zero-sized array causes undefined behaviour when it is not
      the last member in a structure. As it happens to be in this case.
      
      Also, the current code makes use of a language extension to the C90
      standard, but the preferred mechanism to declare variable-length
      types such as this one is a flexible array member, introduced in
      C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last. Which is beneficial
      to cultivate a high-quality code.
      
      Fixes: e48f129c ("[SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5e75d5e2
    • Wen Yang's avatar
      ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put · dc2a8861
      Wen Yang authored
      [ Upstream commit c705247136a523488eac806bd357c3e5d79a7acd ]
      
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./sound/soc/fsl/fsl_utils.c:74:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 38, but without a corresponding     object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Timur Tabi <timur@kernel.org>
      Cc: Nicolin Chen <nicoleotsuka@gmail.com>
      Cc: Xiubo Li <Xiubo.Lee@gmail.com>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dc2a8861
    • Wen Yang's avatar
      ASoC: eukrea-tlv320: fix a leaked reference by adding missing of_node_put · 971e4a27
      Wen Yang authored
      [ Upstream commit b820d52e7eed7b30b2dfef5f4213a2bc3cbea6f3 ]
      
      The call to of_parse_phandle returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
      ./sound/soc/fsl/eukrea-tlv320.c:121:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 102, but without a correspo    nding object release within this function.
      ./sound/soc/fsl/eukrea-tlv320.c:127:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 102, but without a correspo    nding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      971e4a27
    • Nicolas Saenz Julienne's avatar
      HID: core: move Usage Page concatenation to Main item · 5db3c5ad
      Nicolas Saenz Julienne authored
      [ Upstream commit 58e75155009cc800005629955d3482f36a1e0eec ]
      
      As seen on some USB wireless keyboards manufactured by Primax, the HID
      parser was using some assumptions that are not always true. In this case
      it's s the fact that, inside the scope of a main item, an Usage Page
      will always precede an Usage.
      
      The spec is not pretty clear as 6.2.2.7 states "Any usage that follows
      is interpreted as a Usage ID and concatenated with the Usage Page".
      While 6.2.2.8 states "When the parser encounters a main item it
      concatenates the last declared Usage Page with a Usage to form a
      complete usage value." Being somewhat contradictory it was decided to
      match Window's implementation, which follows 6.2.2.8.
      
      In summary, the patch moves the Usage Page concatenation from the local
      item parsing function to the main item parsing function.
      Signed-off-by: default avatarNicolas Saenz Julienne <nsaenzjulienne@suse.de>
      Reviewed-by: default avatarTerry Junge <terry.junge@poly.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5db3c5ad
    • Chengguang Xu's avatar
      chardev: add additional check for minor range overlap · cb7872f1
      Chengguang Xu authored
      [ Upstream commit de36e16d1557a0b6eb328bc3516359a12ba5c25c ]
      
      Current overlap checking cannot correctly handle
      a case which is baseminor < existing baseminor &&
      baseminor + minorct > existing baseminor + minorct.
      Signed-off-by: default avatarChengguang Xu <cgxu519@gmx.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cb7872f1
    • Peter Zijlstra's avatar
      x86/ia32: Fix ia32_restore_sigcontext() AC leak · 5680f59f
      Peter Zijlstra authored
      [ Upstream commit 67a0514afdbb8b2fc70b771b8c77661a9cb9d3a9 ]
      
      Objtool spotted that we call native_load_gs_index() with AC set.
      Re-arrange the code to avoid that.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5680f59f
    • Wen Yang's avatar
      arm64: cpu_ops: fix a leaked reference by adding missing of_node_put · 94032b2e
      Wen Yang authored
      [ Upstream commit 92606ec9285fb84cd9b5943df23f07d741384bfc ]
      
      The call to of_get_next_child returns a node pointer with refcount
      incremented thus it must be explicitly decremented after the last
      usage.
      
      Detected by coccinelle with the following warnings:
        ./arch/arm64/kernel/cpu_ops.c:102:1-7: ERROR: missing of_node_put;
        acquired a node pointer with refcount incremented on line 69, but
        without a corresponding object release within this function.
      Signed-off-by: default avatarWen Yang <wen.yang99@zte.com.cn>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      94032b2e
    • Stanley Chu's avatar
      scsi: ufs: Avoid configuring regulator with undefined voltage range · 04f45a55
      Stanley Chu authored
      [ Upstream commit 3b141e8cfd54ba3e5c610717295b2a02aab26a05 ]
      
      For regulators used by UFS, vcc, vccq and vccq2 will have voltage range
      initialized by ufshcd_populate_vreg(), however other regulators may have
      undefined voltage range if dt-bindings have no such definition.
      
      In above undefined case, both "min_uV" and "max_uV" fields in ufs_vreg
      struct will be zero values and these values will be configured on
      regulators in different power modes.
      
      Currently this may have no harm if both "min_uV" and "max_uV" always keep
      "zero values" because regulator_set_voltage() will always bypass such
      invalid values and return "good" results.
      
      However improper values shall be fixed to avoid potential bugs.  Simply
      bypass voltage configuration if voltage range is not defined.
      Signed-off-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarAvri Altman <avri.altman@wdc.com>
      Acked-by: default avatarAlim Akhtar <alim.akhtar@samsung.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      04f45a55