Skip to content
  1. Jan 18, 2022
  2. Jan 16, 2022
    • Greg Kroah-Hartman's avatar
    • Arnd Bergmann's avatar
      staging: greybus: fix stack size warning with UBSAN · c0091233
      Arnd Bergmann authored
      commit 144779ed upstream.
      
      clang warns about excessive stack usage in this driver when
      UBSAN is enabled:
      
      drivers/staging/greybus/audio_topology.c:977:12: error: stack frame size of 1836 bytes in function 'gbaudio_tplg_create_widget' [-Werror,-Wframe-larger-than=]
      
      Rework this code to no longer use compound literals for
      initializing the structure in each case, but instead keep
      the common bits in a preallocated constant array and copy
      them as needed.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/1535
      Link: https://lore.kernel.org/r/20210103223541.2790855-1-arnd@kernel.org/
      
      
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      [nathan: Address review comments from v1]
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Link: https://lore.kernel.org/r/20211209195141.1165233-1-nathan@kernel.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0091233
    • Nathan Chancellor's avatar
      drm/i915: Avoid bitwise vs logical OR warning in snb_wm_latency_quirk() · 66d21c00
      Nathan Chancellor authored
      commit 2e705706 upstream.
      
      A new warning in clang points out a place in this file where a bitwise
      OR is being used with boolean types:
      
      drivers/gpu/drm/i915/intel_pm.c:3066:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
              changed = ilk_increase_wm_latency(dev_priv, dev_priv->wm.pri_latency, 12) |
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      This construct is intentional, as it allows every one of the calls to
      ilk_increase_wm_latency() to occur (instead of short circuiting with
      logical OR) while still caring about the result of each call.
      
      To make this clearer to the compiler, use the '|=' operator to assign
      the result of each ilk_increase_wm_latency() call to changed, which
      keeps the meaning of the code the same but makes it obvious that every
      one of these calls is expected to happen.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/1473
      
      
      Reported-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Suggested-by: default avatarDávid Bolvanský <david.bolvansky@gmail.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20211014211916.3550122-1-nathan@kernel.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66d21c00
    • Nathan Chancellor's avatar
      staging: wlan-ng: Avoid bitwise vs logical OR warning in hfa384x_usb_throttlefn() · 2d4fda47
      Nathan Chancellor authored
      commit 502408a6 upstream.
      
      A new warning in clang points out a place in this file where a bitwise
      OR is being used with boolean expressions:
      
      In file included from drivers/staging/wlan-ng/prism2usb.c:2:
      drivers/staging/wlan-ng/hfa384x_usb.c:3787:7: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
                  ((test_and_clear_bit(THROTTLE_RX, &hw->usb_flags) &&
                  ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/staging/wlan-ng/hfa384x_usb.c:3787:7: note: cast one or both operands to int to silence this warning
      1 warning generated.
      
      The comment explains that short circuiting here is undesirable, as the
      calls to test_and_{clear,set}_bit() need to happen for both sides of the
      expression.
      
      Clang's suggestion would work to silence the warning but the readability
      of the expression would suffer even more. To clean up the warning and
      make the block more readable, use a variable for each side of the
      bitwise expression.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/1478
      
      
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Link: https://lore.kernel.org/r/20211014215703.3705371-1-nathan@kernel.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d4fda47
    • Ricardo Ribalda's avatar
      media: Revert "media: uvcvideo: Set unique vdev name based in type" · 3609fed7
      Ricardo Ribalda authored
      commit f66dcb32 upstream.
      
      A lot of userspace depends on a descriptive name for vdev. Without this
      patch, users have a hard time figuring out which camera shall they use
      for their video conferencing.
      
      This reverts commit e3f60e7e.
      
      Link: https://lore.kernel.org/linux-media/20211207003840.1212374-2-ribalda@chromium.org
      Cc: <stable@vger.kernel.org>
      Fixes: e3f60e7e
      
       ("media: uvcvideo: Set unique vdev name based in type")
      Reported-by: default avatarNicolas Dufresne <nicolas@ndufresne.ca>
      Signed-off-by: default avatarRicardo Ribalda <ribalda@chromium.org>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Reviewed-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3609fed7
    • Dominik Brodowski's avatar
      random: fix crash on multiple early calls to add_bootloader_randomness() · 9b3c761e
      Dominik Brodowski authored
      commit f7e67b8e
      
       upstream.
      
      Currently, if CONFIG_RANDOM_TRUST_BOOTLOADER is enabled, multiple calls
      to add_bootloader_randomness() are broken and can cause a NULL pointer
      dereference, as noted by Ivan T. Ivanov. This is not only a hypothetical
      problem, as qemu on arm64 may provide bootloader entropy via EFI and via
      devicetree.
      
      On the first call to add_hwgenerator_randomness(), crng_fast_load() is
      executed, and if the seed is long enough, crng_init will be set to 1.
      On subsequent calls to add_bootloader_randomness() and then to
      add_hwgenerator_randomness(), crng_fast_load() will be skipped. Instead,
      wait_event_interruptible() and then credit_entropy_bits() will be called.
      If the entropy count for that second seed is large enough, that proceeds
      to crng_reseed().
      
      However, both wait_event_interruptible() and crng_reseed() depends
      (at least in numa_crng_init()) on workqueues. Therefore, test whether
      system_wq is already initialized, which is a sufficient indicator that
      workqueue_init_early() has progressed far enough.
      
      If we wind up hitting the !system_wq case, we later want to do what
      would have been done there when wqs are up, so set a flag, and do that
      work later from the rand_initialize() call.
      
      Reported-by: default avatarIvan T. Ivanov <iivanov@suse.de>
      Fixes: 18b915ac
      
       ("efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      [Jason: added crng_need_done state and related logic.]
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b3c761e
    • Eric Biggers's avatar
      random: fix data race on crng init time · 61cca7d1
      Eric Biggers authored
      commit 009ba856 upstream.
      
      _extract_crng() does plain loads of crng->init_time and
      crng_global_init_time, which causes undefined behavior if
      crng_reseed() and RNDRESEEDCRNG modify these corrently.
      
      Use READ_ONCE() and WRITE_ONCE() to make the behavior defined.
      
      Don't fix the race on crng->init_time by protecting it with crng->lock,
      since it's not a problem for duplicate reseedings to occur.  I.e., the
      lockless access with READ_ONCE() is fine.
      
      Fixes: d848e5f8 ("random: add new ioctl RNDRESEEDCRNG")
      Fixes: e192be9d
      
       ("random: replace non-blocking pool with a Chacha20-based CRNG")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@kernel.org>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61cca7d1
    • Eric Biggers's avatar
      random: fix data race on crng_node_pool · 3de94782
      Eric Biggers authored
      commit 5d73d1e3 upstream.
      
      extract_crng() and crng_backtrack_protect() load crng_node_pool with a
      plain load, which causes undefined behavior if do_numa_crng_init()
      modifies it concurrently.
      
      Fix this by using READ_ONCE().  Note: as per the previous discussion
      https://lore.kernel.org/lkml/20211219025139.31085-1-ebiggers@kernel.org/T/#u,
      READ_ONCE() is believed to be sufficient here, and it was requested that
      it be used here instead of smp_load_acquire().
      
      Also change do_numa_crng_init() to set crng_node_pool using
      cmpxchg_release() instead of mb() + cmpxchg(), as the former is
      sufficient here but is more lightweight.
      
      Fixes: 1e7f583a
      
       ("random: make /dev/urandom scalable for silly userspace programs")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@kernel.org>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3de94782
    • Brian Silverman's avatar
      can: gs_usb: gs_can_start_xmit(): zero-initialize hf->{flags,reserved} · 43c49429
      Brian Silverman authored
      commit 89d58aeb upstream.
      
      No information is deliberately sent in hf->flags in host -> device
      communications, but the open-source candleLight firmware echoes it
      back, which can result in the GS_CAN_FLAG_OVERFLOW flag being set and
      generating spurious ERRORFRAMEs.
      
      While there also initialize the reserved member with 0.
      
      Fixes: d08e973a ("can: gs_usb: Added support for the GS_USB CAN devices")
      Link: https://lore.kernel.org/all/20220106002952.25883-1-brian.silverman@bluerivertech.com
      Link: https://github.com/candle-usb/candleLight_fw/issues/87
      
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBrian Silverman <brian.silverman@bluerivertech.com>
      [mkl: initialize the reserved member, too]
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43c49429
    • Marc Kleine-Budde's avatar
      can: isotp: convert struct tpcon::{idx,len} to unsigned int · 45221a57
      Marc Kleine-Budde authored
      commit 5f33a09e upstream.
      
      In isotp_rcv_ff() 32 bit of data received over the network is assigned
      to struct tpcon::len. Later in that function the length is checked for
      the maximal supported length against MAX_MSG_LENGTH.
      
      As struct tpcon::len is an "int" this check does not work, if the
      provided length overflows the "int".
      
      Later on struct tpcon::idx is compared against struct tpcon::len.
      
      To fix this problem this patch converts both struct tpcon::{idx,len}
      to unsigned int.
      
      Fixes: e057dd3f ("can: add ISO 15765-2:2016 transport protocol")
      Link: https://lore.kernel.org/all/20220105132429.1170627-1-mkl@pengutronix.de
      
      
      Cc: stable@vger.kernel.org
      Acked-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Reported-by: default avatar <syzbot+4c63f36709a642f801c5@syzkaller.appspotmail.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      45221a57
    • Marc Kleine-Budde's avatar
      can: gs_usb: fix use of uninitialized variable, detach device on reception of invalid USB data · bd61ae80
      Marc Kleine-Budde authored
      commit 4a8737ff upstream.
      
      The received data contains the channel the received data is associated
      with. If the channel number is bigger than the actual number of
      channels assume broken or malicious USB device and shut it down.
      
      This fixes the error found by clang:
      
      | drivers/net/can/usb/gs_usb.c:386:6: error: variable 'dev' is used
      |                                     uninitialized whenever 'if' condition is true
      |         if (hf->channel >= GS_MAX_INTF)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~
      | drivers/net/can/usb/gs_usb.c:474:10: note: uninitialized use occurs here
      |                           hf, dev->gs_hf_size, gs_usb_receive_bulk_callback,
      |                               ^~~
      
      Link: https://lore.kernel.org/all/20211210091158.408326-1-mkl@pengutronix.de
      Fixes: d08e973a
      
       ("can: gs_usb: Added support for the GS_USB CAN devices")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd61ae80
    • Andy Shevchenko's avatar
      mfd: intel-lpss: Fix too early PM enablement in the ACPI ->probe() · f68e6000
      Andy Shevchenko authored
      commit c9e14308 upstream.
      
      The runtime PM callback may be called as soon as the runtime PM facility
      is enabled and activated. It means that ->suspend() may be called before
      we finish probing the device in the ACPI case. Hence, NULL pointer
      dereference:
      
        intel-lpss INT34BA:00: IRQ index 0 not found
        BUG: kernel NULL pointer dereference, address: 0000000000000030
        ...
        Workqueue: pm pm_runtime_work
        RIP: 0010:intel_lpss_suspend+0xb/0x40 [intel_lpss]
      
      To fix this, first try to register the device and only after that enable
      runtime PM facility.
      
      Fixes: 4b45efe8
      
       ("mfd: Add support for Intel Sunrisepoint LPSS devices")
      Reported-by: default avatarOrlando Chamberlain <redecorating@protonmail.com>
      Reported-by: default avatarAditya Garg <gargaditya08@live.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Tested-by: default avatarAditya Garg <gargaditya08@live.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Link: https://lore.kernel.org/r/20211101190008.86473-1-andriy.shevchenko@linux.intel.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f68e6000
    • Daniel Borkmann's avatar
      veth: Do not record rx queue hint in veth_xmit · 5f76445a
      Daniel Borkmann authored
      commit 710ad98c upstream.
      
      Laurent reported that they have seen a significant amount of TCP retransmissions
      at high throughput from applications residing in network namespaces talking to
      the outside world via veths. The drops were seen on the qdisc layer (fq_codel,
      as per systemd default) of the phys device such as ena or virtio_net due to all
      traffic hitting a _single_ TX queue _despite_ multi-queue device. (Note that the
      setup was _not_ using XDP on veths as the issue is generic.)
      
      More specifically, after edbea922 ("veth: Store queue_mapping independently
      of XDP prog presence") which made it all the way back to v4.19.184+,
      skb_record_rx_queue() would set skb->queue_mapping to 1 (given 1 RX and 1 TX
      queue by default for veths) instead of leaving at 0.
      
      This is eventually retained and callbacks like ena_select_queue() will also pick
      single queue via netdev_core_pick_tx()'s ndo_select_queue() once all the traffic
      is forwarded to that device via upper stack or other means. Similarly, for others
      not implementing ndo_select_queue() if XPS is disabled, netdev_pick_tx() might
      call into the skb_tx_hash() and check for prior skb_rx_queue_recorded() as well.
      
      In general, it is a _bad_ idea for virtual devices like veth to mess around with
      queue selection [by default]. Given dev->real_num_tx_queues is by default 1,
      the skb->queue_mapping was left untouched, and so prior to edbea922 the
      netdev_core_pick_tx() could do its job upon __dev_queue_xmit() on the phys device.
      
      Unbreak this and restore prior behavior by removing the skb_record_rx_queue()
      from veth_xmit() altogether.
      
      If the veth peer has an XDP program attached, then it would return the first RX
      queue index in xdp_md->rx_queue_index (unless configured in non-default manner).
      However, this is still better than breaking the generic case.
      
      Fixes: edbea922 ("veth: Store queue_mapping independently of XDP prog presence")
      Fixes: 638264dc
      
       ("veth: Support per queue XDP ring")
      Reported-by: default avatarLaurent Bernaille <laurent.bernaille@datadoghq.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
      Cc: Toshiaki Makita <toshiaki.makita1@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarToshiaki Makita <toshiaki.makita1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f76445a
    • Adrian Hunter's avatar
      mmc: sdhci-pci: Add PCI ID for Intel ADL · ddfa5382
      Adrian Hunter authored
      commit e53e97f8
      
       upstream.
      
      Add PCI ID for Intel ADL eMMC host controller.
      
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20211124094850.1783220-1-adrian.hunter@intel.com
      
      
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ddfa5382
    • Sven Eckelmann's avatar
      ath11k: Fix buffer overflow when scanning with extraie · 2e691f98
      Sven Eckelmann authored
      commit a658c929 upstream.
      
      If cfg80211 is providing extraie's for a scanning process then ath11k will
      copy that over to the firmware. The extraie.len is a 32 bit value in struct
      element_info and describes the amount of bytes for the vendor information
      elements.
      
      The WMI_TLV packet is having a special WMI_TAG_ARRAY_BYTE section. This
      section can have a (payload) length up to 65535 bytes because the
      WMI_TLV_LEN can store up to 16 bits. The code was missing such a check and
      could have created a scan request which cannot be parsed correctly by the
      firmware.
      
      But the bigger problem was the allocation of the buffer. It has to align
      the TLV sections by 4 bytes. But the code was using an u8 to store the
      newly calculated length of this section (with alignment). And the new
      calculated length was then used to allocate the skbuff. But the actual code
      to copy in the data is using the extraie.len and not the calculated
      "aligned" length.
      
      The length of extraie with IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS enabled
      was 264 bytes during tests with a QCA Milan card. But it only allocated 8
      bytes (264 bytes % 256) for it. As consequence, the code to memcpy the
      extraie into the skb was then just overwriting data after skb->end. Things
      like shinfo were therefore corrupted. This could usually be seen by a crash
      in skb_zcopy_clear which tried to call a ubuf_info callback (using a bogus
      address).
      
      Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
      
      Cc: stable@vger.kernel.org
      Fixes: d5c65159
      
       ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20211207142913.1734635-1-sven@narfation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e691f98
    • Alan Stern's avatar
      USB: Fix "slab-out-of-bounds Write" bug in usb_hcd_poll_rh_status · a87cecf9
      Alan Stern authored
      commit 1d7d4c07
      
       upstream.
      
      When the USB core code for getting root-hub status reports was
      originally written, it was assumed that the hub driver would be its
      only caller.  But this isn't true now; user programs can use usbfs to
      communicate with root hubs and get status reports.  When they do this,
      they may use a transfer_buffer that is smaller than the data returned
      by the HCD, which will lead to a buffer overflow error when
      usb_hcd_poll_rh_status() tries to store the status data.  This was
      discovered by syzbot:
      
      BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]
      BUG: KASAN: slab-out-of-bounds in usb_hcd_poll_rh_status+0x5f4/0x780 drivers/usb/core/hcd.c:776
      Write of size 2 at addr ffff88801da403c0 by task syz-executor133/4062
      
      This patch fixes the bug by reducing the amount of status data if it
      won't fit in the transfer_buffer.  If some data gets discarded then
      the URB's completion status is set to -EOVERFLOW rather than 0, to let
      the user know what happened.
      
      Reported-and-tested-by: default avatar <syzbot+3ae6a2b06f131ab9849f@syzkaller.appspotmail.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/Yc+3UIQJ2STbxNua@rowland.harvard.edu
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a87cecf9
    • Alan Stern's avatar
      USB: core: Fix bug in resuming hub's handling of wakeup requests · 15982330
      Alan Stern authored
      commit 0f663729
      
       upstream.
      
      Bugzilla #213839 reports a 7-port hub that doesn't work properly when
      devices are plugged into some of the ports; the kernel goes into an
      unending disconnect/reinitialize loop as shown in the bug report.
      
      This "7-port hub" comprises two four-port hubs with one plugged into
      the other; the failures occur when a device is plugged into one of the
      downstream hub's ports.  (These hubs have other problems too.  For
      example, they bill themselves as USB-2.0 compliant but they only run
      at full speed.)
      
      It turns out that the failures are caused by bugs in both the kernel
      and the hub.  The hub's bug is that it reports a different
      bmAttributes value in its configuration descriptor following a remote
      wakeup (0xe0 before, 0xc0 after -- the wakeup-support bit has
      changed).
      
      The kernel's bug is inside the hub driver's resume handler.  When
      hub_activate() sees that one of the hub's downstream ports got a
      wakeup request from a child device, it notes this fact by setting the
      corresponding bit in the hub->change_bits variable.  But this variable
      is meant for connection changes, not wakeup events; setting it causes
      the driver to believe the downstream port has been disconnected and
      then connected again (in addition to having received a wakeup
      request).
      
      Because of this, the hub driver then tries to check whether the device
      currently plugged into the downstream port is the same as the device
      that had been attached there before.  Normally this check succeeds and
      wakeup handling continues with no harm done (which is why the bug
      remained undetected until now).  But with these dodgy hubs, the check
      fails because the config descriptor has changed.  This causes the hub
      driver to reinitialize the child device, leading to the
      disconnect/reinitialize loop described in the bug report.
      
      The proper way to note reception of a downstream wakeup request is
      to set a bit in the hub->event_bits variable instead of
      hub->change_bits.  That way the hub driver will realize that something
      has happened to the port but will not think the port and child device
      have been disconnected.  This patch makes that change.
      
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarJonathan McDowell <noodles@earth.li>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Link: https://lore.kernel.org/r/YdCw7nSfWYPKWQoD@rowland.harvard.edu
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      15982330
    • Paul Cercueil's avatar
      ARM: dts: exynos: Fix BCM4330 Bluetooth reset polarity in I9100 · 413108ce
      Paul Cercueil authored
      commit 9cb6de45 upstream.
      
      The reset GPIO was marked active-high, which is against what's specified
      in the documentation. Mark the reset GPIO as active-low. With this
      change, Bluetooth can now be used on the i9100.
      
      Fixes: 8620cc2f
      
       ("ARM: dts: exynos: Add devicetree file for the Galaxy S2")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Link: https://lore.kernel.org/r/20211031234137.87070-1-paul@crapouillou.net
      
      
      Signed-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      413108ce
    • Johan Hovold's avatar
      Bluetooth: bfusb: fix division by zero in send path · b6dd0702
      Johan Hovold authored
      commit b5e6fa7a upstream.
      
      Add the missing bulk-out endpoint sanity check to probe() to avoid
      division by zero in bfusb_send_frame() in case a malicious device has
      broken descriptors (or when doing descriptor fuzz testing).
      
      Note that USB core will reject URBs submitted for endpoints with zero
      wMaxPacketSize but that drivers doing packet-size calculations still
      need to handle this (cf. commit 2548288b
      
       ("USB: Fix: Don't skip
      endpoint descriptors with maxpacket=0")).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6dd0702
    • Aaron Ma's avatar
      Bluetooth: btusb: Add support for Foxconn QCA 0xe0d0 · 869e1677
      Aaron Ma authored
      commit 1cd563eb
      
       upstream.
      
      Add an ID of Qualcomm Bluetooth SoC WCN6855.
      
      T:  Bus=05 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  4 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0489 ProdID=e0d0 Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:* If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      I:  If#= 1 Alt= 7 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  65 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  65 Ivl=1ms
      
      Signed-off-by: default avatarAaron Ma <aaron.ma@canonical.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      869e1677
    • Aaron Ma's avatar
      Bluetooth: btusb: Add support for Foxconn MT7922A · c20021ce
      Aaron Ma authored
      commit 69326274
      
       upstream.
      
      Add 2 USB IDs for MT7922A chip.
      These 2 devices got the same description.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
      D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0489 ProdID=e0d8 Rev= 1.00
      
      T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  3 Spd=480  MxCh= 0
      D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0489 ProdID=e0d9 Rev= 1.00
      S:  Manufacturer=MediaTek Inc.
      S:  Product=Wireless_Device
      S:  SerialNumber=000000000
      C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
      E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
      E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
      I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
      E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
      E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
      
      Signed-off-by: default avatarAaron Ma <aaron.ma@canonical.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c20021ce
    • Zijun Hu's avatar
      Bluetooth: btusb: Add two more Bluetooth parts for WCN6855 · 83493918
      Zijun Hu authored
      commit d2666be5
      
       upstream.
      
      Add USB IDs (0x10ab, 0x9309) and (0x10ab, 0x9409) to
      usb_device_id table for WCN6855.
      
      * /sys/kernel/debug/usb/devices
      T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=10ab ProdID=9309 Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      I:  If#= 1 Alt= 7 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  65 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  65 Ivl=1ms
      
      T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=10ab ProdID=9409 Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      I:  If#= 1 Alt= 7 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  65 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  65 Ivl=1ms
      
      Signed-off-by: default avatarZijun Hu <quic_zijuhu@quicinc.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83493918
    • Mark-YW.Chen's avatar
      Bluetooth: btusb: fix memory leak in btusb_mtk_submit_wmt_recv_urb() · 294c0dd8
      Mark-YW.Chen authored
      commit 60c6a63a upstream.
      
      Driver should free `usb->setup_packet` to avoid the leak.
      
      $ cat /sys/kernel/debug/kmemleak
      unreferenced object 0xffffffa564a58080 (size 128):
          backtrace:
              [<000000007eb8dd70>] kmem_cache_alloc_trace+0x22c/0x384
              [<000000008a44191d>] btusb_mtk_hci_wmt_sync+0x1ec/0x994
          [btusb]
              [<00000000ca7189a3>] btusb_mtk_setup+0x6b8/0x13cc
          [btusb]
              [<00000000c6105069>] hci_dev_do_open+0x290/0x974
          [bluetooth]
              [<00000000a583f8b8>] hci_power_on+0xdc/0x3cc [bluetooth]
              [<000000005d80e687>] process_one_work+0x514/0xc80
              [<00000000f4d57637>] worker_thread+0x818/0xd0c
              [<00000000dc7bdb55>] kthread+0x2f8/0x3b8
              [<00000000f9999513>] ret_from_fork+0x10/0x30
      
      Fixes: a1c49c43
      
       ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
      Signed-off-by: default avatarMark-YW.Chen <mark-yw.chen@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      294c0dd8
    • Daniel Borkmann's avatar
      bpf: Fix out of bounds access from invalid *_or_null type verification · 35ab8c90
      Daniel Borkmann authored
      [ no upstream commit given implicitly fixed through the larger refactoring
        in c25b2ae1 ]
      
      While auditing some other code, I noticed missing checks inside the pointer
      arithmetic simulation, more specifically, adjust_ptr_min_max_vals(). Several
      *_OR_NULL types are not rejected whereas they are _required_ to be rejected
      given the expectation is that they get promoted into a 'real' pointer type
      for the success case, that is, after an explicit != NULL check.
      
      One case which stands out and is accessible from unprivileged (iff enabled
      given disabled by default) is BPF ring buffer. From crafting a PoC, the NULL
      check can be bypassed through an offset, and its id marking will then lead
      to promotion of mem_or_null to a mem type.
      
      bpf_ringbuf_reserve() helper can trigger this case through passing of reserved
      flags, for example.
      
        func#0 @0
        0: R1=ctx(id=0,off=0,imm=0) R10=fp0
        0: (7a) *(u64 *)(r10 -8) = 0
        1: R1=ctx(id=0,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm
        1: (18) r1 = 0x0
        3: R1_w=map_ptr(id=0,off=0,ks=0,vs=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm
        3: (b7) r2 = 8
        4: R1_w=map_ptr(id=0,off=0,ks=0,vs=0,imm=0) R2_w=invP8 R10=fp0 fp-8_w=mmmmmmmm
        4: (b7) r3 = 0
        5: R1_w=map_ptr(id=0,off=0,ks=0,vs=0,imm=0) R2_w=invP8 R3_w=invP0 R10=fp0 fp-8_w=mmmmmmmm
        5: (85) call bpf_ringbuf_reserve#131
        6: R0_w=mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        6: (bf) r6 = r0
        7: R0_w=mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R6_w=mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        7: (07) r0 += 1
        8: R0_w=mem_or_null(id=2,ref_obj_id=2,off=1,imm=0) R6_w=mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        8: (15) if r0 == 0x0 goto pc+4
         R0_w=mem(id=0,ref_obj_id=0,off=0,imm=0) R6_w=mem(id=0,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        9: R0_w=mem(id=0,ref_obj_id=0,off=0,imm=0) R6_w=mem(id=0,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        9: (62) *(u32 *)(r6 +0) = 0
         R0_w=mem(id=0,ref_obj_id=0,off=0,imm=0) R6_w=mem(id=0,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        10: R0_w=mem(id=0,ref_obj_id=0,off=0,imm=0) R6_w=mem(id=0,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        10: (bf) r1 = r6
        11: R0_w=mem(id=0,ref_obj_id=0,off=0,imm=0) R1_w=mem(id=0,ref_obj_id=2,off=0,imm=0) R6_w=mem(id=0,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        11: (b7) r2 = 0
        12: R0_w=mem(id=0,ref_obj_id=0,off=0,imm=0) R1_w=mem(id=0,ref_obj_id=2,off=0,imm=0) R2_w=invP0 R6_w=mem(id=0,ref_obj_id=2,off=0,imm=0) R10=fp0 fp-8_w=mmmmmmmm refs=2
        12: (85) call bpf_ringbuf_submit#132
        13: R6=invP(id=0) R10=fp0 fp-8=mmmmmmmm
        13: (b7) r0 = 0
        14: R0_w=invP0 R6=invP(id=0) R10=fp0 fp-8=mmmmmmmm
        14: (95) exit
      
        from 8 to 13: safe
        processed 15 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 0
        OK
      
      All three commits, that is b121b341 ("bpf: Add PTR_TO_BTF_ID_OR_NULL support"),
      457f4436 ("bpf: Implement BPF ring buffer and verifier support for it"), and the
      afbf21dc ("bpf: Support readonly/readwrite buffers in verifier") suffer the same
      cause and their *_OR_NULL type pendants must be rejected in adjust_ptr_min_max_vals().
      
      Make the test more robust by reusing reg_type_may_be_null() helper such that we catch
      all *_OR_NULL types we have today and in future.
      
      Note that pointer arithmetic on PTR_TO_BTF_ID, PTR_TO_RDONLY_BUF, and PTR_TO_RDWR_BUF
      is generally allowed.
      
      Fixes: b121b341 ("bpf: Add PTR_TO_BTF_ID_OR_NULL support")
      Fixes: 457f4436 ("bpf: Implement BPF ring buffer and verifier support for it")
      Fixes: afbf21dc
      
       ("bpf: Support readonly/readwrite buffers in verifier")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35ab8c90
    • Frederic Weisbecker's avatar
      workqueue: Fix unbind_workers() VS wq_worker_running() race · c84fbba8
      Frederic Weisbecker authored
      commit 07edfece upstream.
      
      At CPU-hotplug time, unbind_worker() may preempt a worker while it is
      waking up. In that case the following scenario can happen:
      
              unbind_workers()                     wq_worker_running()
              --------------                      -------------------
              	                      if (!(worker->flags & WORKER_NOT_RUNNING))
              	                          //PREEMPTED by unbind_workers
              worker->flags |= WORKER_UNBOUND;
              [...]
              atomic_set(&pool->nr_running, 0);
              //resume to worker
      		                              atomic_inc(&worker->pool->nr_running);
      
      After unbind_worker() resets pool->nr_running, the value is expected to
      remain 0 until the pool ever gets rebound in case cpu_up() is called on
      the target CPU in the future. But here the race leaves pool->nr_running
      with a value of 1, triggering the following warning when the worker goes
      idle:
      
      	WARNING: CPU: 3 PID: 34 at kernel/workqueue.c:1823 worker_enter_idle+0x95/0xc0
      	Modules linked in:
      	CPU: 3 PID: 34 Comm: kworker/3:0 Not tainted 5.16.0-rc1+ #34
      	Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
      	Workqueue:  0x0 (rcu_par_gp)
      	RIP: 0010:worker_enter_idle+0x95/0xc0
      	Code: 04 85 f8 ff ff ff 39 c1 7f 09 48 8b 43 50 48 85 c0 74 1b 83 e2 04 75 99 8b 43 34 39 43 30 75 91 8b 83 00 03 00 00 85 c0 74 87 <0f> 0b 5b c3 48 8b 35 70 f1 37 01 48 8d 7b 48 48 81 c6 e0 93  0
      	RSP: 0000:ffff9b7680277ed0 EFLAGS: 00010086
      	RAX: 00000000ffffffff RBX: ffff93465eae9c00 RCX: 0000000000000000
      	RDX: 0000000000000000 RSI: ffff9346418a0000 RDI: ffff934641057140
      	RBP: ffff934641057170 R08: 0000000000000001 R09: ffff9346418a0080
      	R10: ffff9b768027fdf0 R11: 0000000000002400 R12: ffff93465eae9c20
      	R13: ffff93465eae9c20 R14: ffff93465eae9c70 R15: ffff934641057140
      	FS:  0000000000000000(0000) GS:ffff93465eac0000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 0000000000000000 CR3: 000000001cc0c000 CR4: 00000000000006e0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      	Call Trace:
      	  <TASK>
      	  worker_thread+0x89/0x3d0
      	  ? process_one_work+0x400/0x400
      	  kthread+0x162/0x190
      	  ? set_kthread_struct+0x40/0x40
      	  ret_from_fork+0x22/0x30
      	  </TASK>
      
      Also due to this incorrect "nr_running == 1", further queued work may
      end up not being served, because no worker is awaken at work insert time.
      This raises rcutorture writer stalls for example.
      
      Fix this with disabling preemption in the right place in
      wq_worker_running().
      
      It's worth noting that if the worker migrates and runs concurrently with
      unbind_workers(), it is guaranteed to see the WORKER_UNBOUND flag update
      due to set_cpus_allowed_ptr() acquiring/releasing rq->lock.
      
      Fixes: 6d25be57
      
       ("sched/core, workqueues: Distangle worker accounting from rq lock")
      Reviewed-by: default avatarLai Jiangshan <jiangshanlai@gmail.com>
      Tested-by: default avatarPaul E. McKenney <paulmck@kernel.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarFrederic Weisbecker <frederic@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c84fbba8
    • Guoqing Jiang's avatar
      md: revert io stats accounting · c39d68ab
      Guoqing Jiang authored
      commit ad3fc798 upstream.
      
      The commit 41d2d848 ("md: improve io stats accounting") could cause
      double fault problem per the report [1], and also it is not correct to
      change ->bi_end_io if md don't own it, so let's revert it.
      
      And io stats accounting will be replemented in later commits.
      
      [1]. https://lore.kernel.org/linux-raid/3bf04253-3fad-434a-63a7-20214e38cf26@gmail.com/T/#t
      
      Fixes: 41d2d848
      
       ("md: improve io stats accounting")
      Signed-off-by: default avatarGuoqing Jiang <jiangguoqing@kylinos.cn>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      [GM: backport to 5.10-stable]
      Signed-off-by: default avatarGuillaume Morin <guillaume@morinfr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c39d68ab
  3. Jan 15, 2022
  4. Jan 14, 2022
  5. Jan 13, 2022
  6. Jan 12, 2022
  7. Jan 11, 2022