This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git. Pull mirroring updated .
  1. 15 Jan, 2022 7 commits
  2. 14 Jan, 2022 2 commits
  3. 27 Dec, 2021 2 commits
  4. 22 Dec, 2021 24 commits
    • Greg Kroah-Hartman's avatar
    • Juergen Gross's avatar
      xen/netback: don't queue unlimited number of packages · 0928efb0
      Juergen Gross authored
      commit be81992f9086b230623ae3ebbc85ecee4d00a3d3 upstream.
      
      In case a guest isn't consuming incoming network traffic as fast as it
      is coming in, xen-netback is buffering network packages in unlimited
      numbers today. This can result in host OOM situations.
      
      Commit f48da8b1 ("xen-netback: fix unlimited guest Rx internal
      queue and carrier flapping") meant to introduce a mechanism to limit
      the amount of buffered data by stopping the Tx queue when reaching the
      data limit, but this doesn't work for cases like UDP.
      
      When hitting the limit don't queue further SKBs, but drop them instead.
      In order to be able to tell Rx packages have been dropped increment the
      rx_dropped statistics counter in this case.
      
      It should be noted that the old solution to continue queueing SKBs had
      the additional problem of an overflow of the 32-bit rx_queue_len value
      would result in intermittent Tx queue enabling.
      
      This is part of XSA-392
      
      Fixes: f48da8b1
      
       ("xen-netback: fix unlimited guest Rx internal queue and carrier flapping")
      Signed-off-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0928efb0
    • Juergen Gross's avatar
      xen/console: harden hvc_xen against event channel storms · c7eaa508
      Juergen Gross authored
      
      
      commit fe415186b43df0db1f17fa3a46275fd92107fe71 upstream.
      
      The Xen console driver is still vulnerable for an attack via excessive
      number of events sent by the backend. Fix that by using a lateeoi event
      channel.
      
      For the normal domU initial console this requires the introduction of
      bind_evtchn_to_irq_lateeoi() as there is no xenbus device available
      at the time the event channel is bound to the irq.
      
      As the decision whether an interrupt was spurious or not requires to
      test for bytes having been read from the backend, move sending the
      event into the if statement, as sending an event without having found
      any bytes to be read is making no sense at all.
      
      This is part of XSA-391
      Signed-off-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7eaa508
    • Juergen Gross's avatar
      xen/netfront: harden netfront against event channel storms · 81900aa7
      Juergen Gross authored
      
      
      commit b27d47950e481f292c0a5ad57357edb9d95d03ba upstream.
      
      The Xen netfront driver is still vulnerable for an attack via excessive
      number of events sent by the backend. Fix that by using lateeoi event
      channels.
      
      For being able to detect the case of no rx responses being added while
      the carrier is down a new lock is needed in order to update and test
      rsp_cons and the number of seen unconsumed responses atomically.
      
      This is part of XSA-391
      Signed-off-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81900aa7
    • Juergen Gross's avatar
      xen/blkfront: harden blkfront against event channel storms · 3e04b9e6
      Juergen Gross authored
      
      
      commit 0fd08a34e8e3b67ec9bd8287ac0facf8374b844a upstream.
      
      The Xen blkfront driver is still vulnerable for an attack via excessive
      number of events sent by the backend. Fix that by using lateeoi event
      channels.
      
      This is part of XSA-391
      Signed-off-by: Juergen Gross's avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: Jan Beulich's avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e04b9e6
    • Nathan Chancellor's avatar
      Input: touchscreen - avoid bitwise vs logical OR warning · 57871aeb
      Nathan Chancellor authored
      
      
      commit a02dcde595f7cbd240ccd64de96034ad91cffc40 upstream.
      
      A new warning in clang points out a few places in this driver where a
      bitwise OR is being used with boolean types:
      
      drivers/input/touchscreen.c:81:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
              data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      This use of a bitwise OR is intentional, as bitwise operations do not
      short circuit, which allows all the calls to touchscreen_get_prop_u32()
      to happen so that the last parameter is initialized while coalescing the
      results of the calls to make a decision after they are all evaluated.
      
      To make this clearer to the compiler, use the '|=' operator to assign
      the result of each touchscreen_get_prop_u32() call to data_present,
      which keeps the meaning of the code the same but makes it obvious that
      every one of these calls is expected to happen.
      Signed-off-by: Nathan Chancellor's avatarNathan Chancellor <nathan@kernel.org>
      Reported-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Link: https://lore.kernel.org/r/20211014205757.3474635-1-nathan@kernel.org
      
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57871aeb
    • Nicolas Pitre's avatar
      ARM: 8805/2: remove unneeded naked function usage · 38c76c66
      Nicolas Pitre authored
      commit b99afae1 upstream.
      
      The naked attribute is known to confuse some old gcc versions when
      function arguments aren't explicitly listed as inline assembly operands
      despite the gcc documentation. That resulted in commit 9a40ac86
      
      
      ("ARM: 6164/1: Add kto and kfrom to input operands list.").
      
      Yet that commit has problems of its own by having assembly operand
      constraints completely wrong. If the generated code has been OK since
      then, it is due to luck rather than correctness. So this patch also
      provides proper assembly operand constraints, and removes two instances
      of redundant register usages in the implementation while at it.
      
      Inspection of the generated code with this patch doesn't show any
      obvious quality degradation either, so not relying on __naked at all
      will make the code less fragile, and avoid some issues with clang.
      
      The only remaining __naked instances (excluding the kprobes test cases)
      are exynos_pm_power_up_setup(), tc2_pm_power_up_setup() and
      
      cci_enable_port_for_self(. But in the first two cases, only the function
      address is used by the compiler with no chance of inlining it by
      mistake, and the third case is called from assembly code only. And the
      fact that no stack is available when the corresponding code is executed
      does warrant the __naked usage in those cases.
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Reviewed-by: Stefan Agner's avatarStefan Agner <stefan@agner.ch>
      Tested-by: Stefan Agner's avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38c76c66
    • Nathan Chancellor's avatar
      net: lan78xx: Avoid unnecessary self assignment · cd98c0b5
      Nathan Chancellor authored
      commit 94e7c844 upstream.
      
      Clang warns when a variable is assigned to itself.
      
      drivers/net/usb/lan78xx.c:940:11: warning: explicitly assigning value of
      variable of type 'u32' (aka 'unsigned int') to itself [-Wself-assign]
                              offset = offset;
                              ~~~~~~ ^ ~~~~~~
      1 warning generated.
      
      Reorder the if statement to acheive the same result and avoid a self
      assignment warning.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/129
      
      Signed-off-by: Nathan Chancellor's avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd98c0b5
    • Florian Fainelli's avatar
      net: systemport: Add global locking for descriptor lifecycle · 8ed2f5d0
      Florian Fainelli authored
      commit 8b8e6e782456f1ce02a7ae914bbd5b1053f0b034 upstream.
      
      The descriptor list is a shared resource across all of the transmit queues, and
      the locking mechanism used today only protects concurrency across a given
      transmit queue between the transmit and reclaiming. This creates an opportunity
      for the SYSTEMPORT hardware to work on corrupted descriptors if we have
      multiple producers at once which is the case when using multiple transmit
      queues.
      
      This was particularly noticeable when using multiple flows/transmit queues and
      it showed up in interesting ways in that UDP packets would get a correct UDP
      header checksum being calculated over an incorrect packet length. Similarly TCP
      packets would get an equally correct checksum computed by the hardware over an
      incorrect packet length.
      
      The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges
      when the driver produces a new descriptor anytime it writes to the
      WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to
      re-organize its descriptors and it is possible that concurrent TX queues
      eventually break this internal allocation scheme to the point where the
      length/status part of the descriptor gets used for an incorrect data buffer.
      
      The fix is to impose a global serialization for all TX queues in the short
      section where we are writing to the WRITE_PORT_{HI,LO} registers which solves
      the corruption even with multiple concurrent TX queues being used.
      
      Fixes: 80105bef
      
       ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20211215202450.4086240-1-f.fainelli@gmail.com
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ed2f5d0
    • Yu Liao's avatar
      timekeeping: Really make sure wall_to_monotonic isn't positive · ed5dc41b
      Yu Liao authored
      commit 4e8c11b6b3f0b6a283e898344f154641eda94266 upstream.
      
      Even after commit e1d7ba87 ("time: Always make sure wall_to_monotonic
      isn't positive") it is still possible to make wall_to_monotonic positive
      by running the following code:
      
          int main(void)
          {
              struct timespec time;
      
              clock_gettime(CLOCK_MONOTONIC, &time);
              time.tv_nsec = 0;
              clock_settime(CLOCK_REALTIME, &time);
              return 0;
          }
      
      The reason is that the second parameter of timespec64_compare(), ts_delta,
      may be unnormalized because the delta is calculated with an open coded
      substraction which causes the comparison of tv_sec to yield the wrong
      result:
      
        wall_to_monotonic = { .tv_sec = -10, .tv_nsec =  900000000 }
        ts_delta 	    = { .tv_sec =  -9, .tv_nsec = -900000000 }
      
      That makes timespec64_compare() claim that wall_to_monotonic < ts_delta,
      but actually the result should be wall_to_monotonic > ts_delta.
      
      After normalization, the result of timespec64_compare() is correct because
      the tv_sec comparison is not longer misleading:
      
        wall_to_monotonic = { .tv_sec = -10, .tv_nsec =  900000000 }
        ts_delta 	    = { .tv_sec = -10, .tv_nsec =  100000000 }
      
      Use timespec64_sub() to ensure that ts_delta is normalized, which fixes the
      issue.
      
      Fixes: e1d7ba87
      
       ("time: Always make sure wall_to_monotonic isn't positive")
      Signed-off-by: default avatarYu Liao <liaoyu15@huawei.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20211213135727.1656662-1-liaoyu15@huawei.com
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed5dc41b
    • Daniele's avatar
      USB: serial: option: add Telit FN990 compositions · 9d4ded7c
      Daniele authored
      
      
      commit 2b503c8598d1b232e7fc7526bce9326d92331541 upstream.
      
      Add the following Telit FN990 compositions:
      
      0x1070: tty, adb, rmnet, tty, tty, tty, tty
      0x1071: tty, adb, mbim, tty, tty, tty, tty
      0x1072: rndis, tty, adb, tty, tty, tty, tty
      0x1073: tty, adb, ecm, tty, tty, tty, tty
      Signed-off-by: Daniele's avatarDaniele Palmas <dnlplm@gmail.com>
      Link: https://lore.kernel.org/r/20211210100714.22587-1-dnlplm@gmail.com
      
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d4ded7c
    • Thomas Gleixner's avatar
      PCI/MSI: Clear PCI_MSIX_FLAGS_MASKALL on error · 814e0405
      Thomas Gleixner authored
      
      
      commit 94185adbfad56815c2c8401e16d81bdb74a79201 upstream.
      
      PCI_MSIX_FLAGS_MASKALL is set in the MSI-X control register at MSI-X
      interrupt setup time. It's cleared on success, but the error handling path
      only clears the PCI_MSIX_FLAGS_ENABLE bit.
      
      That's incorrect as the reset state of the PCI_MSIX_FLAGS_MASKALL bit is
      zero. That can be observed via lspci:
      
              Capabilities: [b0] MSI-X: Enable- Count=67 Masked+
      
      Clear the bit in the error path to restore the reset state.
      
      Fixes: 438553958ba1 ("PCI/MSI: Enable and mask MSI-X early")
      Reported-by: default avatarStefan Roese <sr@denx.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarStefan Roese <sr@denx.de>
      Cc: linux-pci@vger.kernel.org
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/87tufevoqx.ffs@tglx
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      814e0405
    • Greg Kroah-Hartman's avatar
      USB: gadget: bRequestType is a bitfield, not a enum · 2983866f
      Greg Kroah-Hartman authored
      
      
      [ Upstream commit f08adf5add9a071160c68bb2a61d697f39ab0758 ]
      
      Szymon rightly pointed out that the previous check for the endpoint
      direction in bRequestType was not looking at only the bit involved, but
      rather the whole value.  Normally this is ok, but for some request
      types, bits other than bit 8 could be set and the check for the endpoint
      length could not stall correctly.
      
      Fix that up by only checking the single bit.
      
      Fixes: 153a2d7e3350 ("USB: gadget: detect too-big endpoint 0 requests")
      Cc: Felipe Balbi <balbi@kernel.org>
      Reported-by: default avatarSzymon Heidrich <szymon.heidrich@gmail.com>
      Link: https://lore.kernel.org/r/20211214184621.385828-1-gregkh@linuxfoundation.org
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2983866f
    • Letu Ren's avatar
      igbvf: fix double free in `igbvf_probe` · ffe1695b
      Letu Ren authored
      [ Upstream commit b6d335a6 ]
      
      In `igbvf_probe`, if register_netdev() fails, the program will go to
      label err_hw_init, and then to label err_ioremap. In free_netdev() which
      is just below label err_ioremap, there is `list_for_each_entry_safe` and
      `netif_napi_del` which aims to delete all entries in `dev->napi_list`.
      The program has added an entry `adapter->rx_ring->napi` which is added by
      `netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has
      been freed below label err_hw_init. So this a UAF.
      
      In terms of how to patch the problem, we can refer to igbvf_remove() and
      delete the entry before `adapter->rx_ring`.
      
      The KASAN logs are as follows:
      
      [   35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450
      [   35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366
      [   35.128360]
      [   35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14
      [   35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
      [   35.131749] Call Trace:
      [   35.132199]  dump_stack_lvl+0x59/0x7b
      [   35.132865]  print_address_description+0x7c/0x3b0
      [   35.133707]  ? free_netdev+0x1fd/0x450
      [   35.134378]  __kasan_report+0x160/0x1c0
      [   35.135063]  ? free_netdev+0x1fd/0x450
      [   35.135738]  kasan_report+0x4b/0x70
      [   35.136367]  free_netdev+0x1fd/0x450
      [   35.137006]  igbvf_probe+0x121d/0x1a10 [igbvf]
      [   35.137808]  ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]
      [   35.138751]  local_pci_probe+0x13c/0x1f0
      [   35.139461]  pci_device_probe+0x37e/0x6c0
      [   35.165526]
      [   35.165806] Allocated by task 366:
      [   35.166414]  ____kasan_kmalloc+0xc4/0xf0
      [   35.167117]  foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]
      [   35.168078]  igbvf_probe+0x9c5/0x1a10 [igbvf]
      [   35.168866]  local_pci_probe+0x13c/0x1f0
      [   35.169565]  pci_device_probe+0x37e/0x6c0
      [   35.179713]
      [   35.179993] Freed by task 366:
      [   35.180539]  kasan_set_track+0x4c/0x80
      [   35.181211]  kasan_set_free_info+0x1f/0x40
      [   35.181942]  ____kasan_slab_free+0x103/0x140
      [   35.182703]  kfree+0xe3/0x250
      [   35.183239]  igbvf_probe+0x1173/0x1a10 [igbvf]
      [   35.184040]  local_pci_probe+0x13c/0x1f0
      
      Fixes: d4e0fe01
      
       (igbvf: add new driver to support 82576 virtual functions)
      Reported-by: 马哲宇's avatarZheyu Ma <zheyuma97@gmail.com>
      Signed-off-by: Letu Ren's avatarLetu Ren <fantasquex@gmail.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ffe1695b
    • Nathan Chancellor's avatar
      soc/tegra: fuse: Fix bitwise vs. logical OR warning · 22feeef2
      Nathan Chancellor authored
      [ Upstream commit a7083763619f7485ccdade160deb81737cf2732f ]
      
      A new warning in clang points out two instances where boolean
      expressions are being used with a bitwise OR instead of logical OR:
      
      drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
                      reg = tegra_fuse_read_spare(i) |
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~
                                                     ||
      drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: note: cast one or both operands to int to silence this warning
      drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
                      reg = tegra_fuse_read_spare(i) |
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~
                                                     ||
      drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: note: cast one or both operands to int to silence this warning
      2 warnings generated.
      
      The motivation for the warning is that logical operations short circuit
      while bitwise operations do not.
      
      In this instance, tegra_fuse_read_spare() is not semantically returning
      a boolean, it is returning a bit value. Use u32 for its return type so
      that it can be used with either bitwise or boolean operators without any
      warnings.
      
      Fixes: 25cd5a39 ("ARM: tegra: Add speedo-based process identification")
      Link: https://github.com/ClangBuiltLinux/linux/issues/1488
      
      Suggested-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Signed-off-by: Nathan Chancellor's avatarNathan Chancellor <nathan@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      22feeef2
    • J. Bruce Fields's avatar
      nfsd: fix use-after-free due to delegation race · 04a8d07f
      J. Bruce Fields authored
      
      
      commit 548ec0805c399c65ed66c6641be467f717833ab5 upstream.
      
      A delegation break could arrive as soon as we've called vfs_setlease.  A
      delegation break runs a callback which immediately (in
      nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru.  If we
      then exit nfs4_set_delegation without hashing the delegation, it will be
      freed as soon as the callback is done with it, without ever being
      removed from del_recall_lru.
      
      Symptoms show up later as use-after-free or list corruption warnings,
      usually in the laundromat thread.
      
      I suspect aba2072f4523 "nfsd: grant read delegations to clients holding
      writes" made this bug easier to hit, but I looked as far back as v3.0
      and it looks to me it already had the same problem.  So I'm not sure
      where the bug was introduced; it may have been there from the beginning.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: J. Bruce Fields's avatarJ. Bruce Fields <bfields@redhat.com>
      [Salvatore Bonaccorso: Backport for context changes to versions which do
      not have 20b7d86f
      
       ("nfsd: use boottime for lease expiry calculation")]
      Signed-off-by: Salvatore Bonaccorso's avatarSalvatore Bonaccorso <carnil@debian.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04a8d07f
    • Joe Thornber's avatar
      dm btree remove: fix use after free in rebalance_children() · a48f6a2b
      Joe Thornber authored
      commit 1b8d2789
      
       upstream.
      
      Move dm_tm_unlock() after dm_tm_dec().
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: Mike Snitzer's avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a48f6a2b
    • Jerome Marchand's avatar
      recordmcount.pl: look for jgnop instruction as well as bcrl on s390 · 23760c59
      Jerome Marchand authored
      
      
      commit 85bf17b28f97ca2749968d8786dc423db320d9c2 upstream.
      
      On s390, recordmcount.pl is looking for "bcrl 0,<xxx>" instructions in
      the objdump -d outpout. However since binutils 2.37, objdump -d
      display "jgnop <xxx>" for the same instruction. Update the
      mcount_regex so that it accepts both.
      Signed-off-by: Jerome Marchand's avatarJerome Marchand <jmarchan@redhat.com>
      Reviewed-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20211210093827.1623286-1-jmarchan@redhat.com
      
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23760c59
    • Felix Fietkau's avatar
      mac80211: send ADDBA requests using the tid/queue of the aggregation session · 6ff89cda
      Felix Fietkau authored
      commit 1fe98f56
      
       upstream.
      
      Sending them out on a different queue can cause a race condition where a
      number of packets in the queue may be discarded by the receiver, because
      the ADDBA request is sent too early.
      This affects any driver with software A-MPDU setup which does not allocate
      packet seqno in hardware on tx, regardless of whether iTXQ is used or not.
      The only driver I've seen that explicitly deals with this issue internally
      is mwl8k.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: Felix Fietkau's avatarFelix Fietkau <nbd@nbd.name>
      Link: https://lore.kernel.org/r/20211202124533.80388-1-nbd@nbd.name
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ff89cda
    • Armin Wolf's avatar
      hwmon: (dell-smm) Fix warning on /proc/i8k creation error · d6a8a0fc
      Armin Wolf authored
      commit dbd3e6eaf3d813939b28e8a66e29d81cdc836445 upstream.
      
      The removal function is called regardless of whether
      /proc/i8k was created successfully or not, the later
      causing a WARN() on module removal.
      Fix that by only registering the removal function
      if /proc/i8k was created successfully.
      
      Tested on a Inspiron 3505.
      
      Fixes: 039ae585
      
       ("hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k")
      Signed-off-by: default avatarArmin Wolf <W_Armin@gmx.de>
      Acked-by: default avatarPali Rohár <pali@kernel.org>
      Link: https://lore.kernel.org/r/20211112171440.59006-1-W_Armin@gmx.de
      
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6a8a0fc
    • Harshit Mogalapalli's avatar
      net: netlink: af_netlink: Prevent empty skb by adding a check on len. · c54a60c8
      Harshit Mogalapalli authored
      [ Upstream commit f123cffd
      
       ]
      
      Adding a check on len parameter to avoid empty skb. This prevents a
      division error in netem_enqueue function which is caused when skb->len=0
      and skb->data_len=0 in the randomized corruption step as shown below.
      
      skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);
      
      Crash Report:
      [  343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family
      0 port 6081 - 0
      [  343.216110] netem: version 1.3
      [  343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
      [  343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+
      [  343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      BIOS 1.11.0-2.el7 04/01/2014
      [  343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]
      [  343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff
      ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f
      74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03
      [  343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246
      [  343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:
      0000000000000000
      [  343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:
      ffff88800f8eda40
      [  343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:
      ffffffff94fb8445
      [  343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:
      0000000000000000
      [  343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:
      0000000000000020
      [  343.247291] FS:  00007fdde2bd7700(0000) GS:ffff888109780000(0000)
      knlGS:0000000000000000
      [  343.248350] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:
      00000000000006e0
      [  343.250076] Call Trace:
      [  343.250423]  <TASK>
      [  343.250713]  ? memcpy+0x4d/0x60
      [  343.251162]  ? netem_init+0xa0/0xa0 [sch_netem]
      [  343.251795]  ? __sanitizer_cov_trace_pc+0x21/0x60
      [  343.252443]  netem_enqueue+0xe28/0x33c0 [sch_netem]
      [  343.253102]  ? stack_trace_save+0x87/0xb0
      [  343.253655]  ? filter_irq_stacks+0xb0/0xb0
      [  343.254220]  ? netem_init+0xa0/0xa0 [sch_netem]
      [  343.254837]  ? __kasan_check_write+0x14/0x20
      [  343.255418]  ? _raw_spin_lock+0x88/0xd6
      [  343.255953]  dev_qdisc_enqueue+0x50/0x180
      [  343.256508]  __dev_queue_xmit+0x1a7e/0x3090
      [  343.257083]  ? netdev_core_pick_tx+0x300/0x300
      [  343.257690]  ? check_kcov_mode+0x10/0x40
      [  343.258219]  ? _raw_spin_unlock_irqrestore+0x29/0x40
      [  343.258899]  ? __kasan_init_slab_obj+0x24/0x30
      [  343.259529]  ? setup_object.isra.71+0x23/0x90
      [  343.260121]  ? new_slab+0x26e/0x4b0
      [  343.260609]  ? kasan_poison+0x3a/0x50
      [  343.261118]  ? kasan_unpoison+0x28/0x50
      [  343.261637]  ? __kasan_slab_alloc+0x71/0x90
      [  343.262214]  ? memcpy+0x4d/0x60
      [  343.262674]  ? write_comp_data+0x2f/0x90
      [  343.263209]  ? __kasan_check_write+0x14/0x20
      [  343.263802]  ? __skb_clone+0x5d6/0x840
      [  343.264329]  ? __sanitizer_cov_trace_pc+0x21/0x60
      [  343.264958]  dev_queue_xmit+0x1c/0x20
      [  343.265470]  netlink_deliver_tap+0x652/0x9c0
      [  343.266067]  netlink_unicast+0x5a0/0x7f0
      [  343.266608]  ? netlink_attachskb+0x860/0x860
      [  343.267183]  ? __sanitizer_cov_trace_pc+0x21/0x60
      [  343.267820]  ? write_comp_data+0x2f/0x90
      [  343.268367]  netlink_sendmsg+0x922/0xe80
      [  343.268899]  ? netlink_unicast+0x7f0/0x7f0
      [  343.269472]  ? __sanitizer_cov_trace_pc+0x21/0x60
      [  343.270099]  ? write_comp_data+0x2f/0x90
      [  343.270644]  ? netlink_unicast+0x7f0/0x7f0
      [  343.271210]  sock_sendmsg+0x155/0x190
      [  343.271721]  ____sys_sendmsg+0x75f/0x8f0
      [  343.272262]  ? kernel_sendmsg+0x60/0x60
      [  343.272788]  ? write_comp_data+0x2f/0x90
      [  343.273332]  ? write_comp_data+0x2f/0x90
      [  343.273869]  ___sys_sendmsg+0x10f/0x190
      [  343.274405]  ? sendmsg_copy_msghdr+0x80/0x80
      [  343.274984]  ? slab_post_alloc_hook+0x70/0x230
      [  343.275597]  ? futex_wait_setup+0x240/0x240
      [  343.276175]  ? security_file_alloc+0x3e/0x170
      [  343.276779]  ? write_comp_data+0x2f/0x90
      [  343.277313]  ? __sanitizer_cov_trace_pc+0x21/0x60
      [  343.277969]  ? write_comp_data+0x2f/0x90
      [  343.278515]  ? __fget_files+0x1ad/0x260
      [  343.279048]  ? __sanitizer_cov_trace_pc+0x21/0x60
      [  343.279685]  ? write_comp_data+0x2f/0x90
      [  343.280234]  ? __sanitizer_cov_trace_pc+0x21/0x60
      [  343.280874]  ? sockfd_lookup_light+0xd1/0x190
      [  343.281481]  __sys_sendmsg+0x118/0x200
      [  343.281998]  ? __sys_sendmsg_sock+0x40/0x40
      [  343.282578]  ? alloc_fd+0x229/0x5e0
      [  343.283070]  ? write_comp_data+0x2f/0x90
      [  343.283610]  ? write_comp_data+0x2f/0x90
      [  343.284135]  ? __sanitizer_cov_trace_pc+0x21/0x60
      [  343.284776]  ? ktime_get_coarse_real_ts64+0xb8/0xf0
      [  343.285450]  __x64_sys_sendmsg+0x7d/0xc0
      [  343.285981]  ? syscall_enter_from_user_mode+0x4d/0x70
      [  343.286664]  do_syscall_64+0x3a/0x80
      [  343.287158]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [  343.287850] RIP: 0033:0x7fdde24cf289
      [  343.288344] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00
      48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f
      05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b7 db 2c 00 f7 d8 64 89 01 48
      [  343.290729] RSP: 002b:00007fdde2bd6d98 EFLAGS: 00000246 ORIG_RAX:
      000000000000002e
      [  343.291730] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
      00007fdde24cf289
      [  343.292673] RDX: 0000000000000000 RSI: 00000000200000c0 RDI:
      0000000000000004
      [  343.293618] RBP: 00007fdde2bd6e20 R08: 0000000100000001 R09:
      0000000000000000
      [  343.294557] R10: 0000000100000001 R11: 0000000000000246 R12:
      0000000000000000
      [  343.295493] R13: 0000000000021000 R14: 0000000000000000 R15:
      00007fdde2bd7700
      [  343.296432]  </TASK>
      [  343.296735] Modules linked in: sch_netem ip6_vti ip_vti ip_gre ipip
      sit ip_tunnel geneve macsec macvtap tap ipvlan macvlan 8021q garp mrp
      hsr wireguard libchacha20poly1305 chacha_x86_64 poly1305_x86_64
      ip6_udp_tunnel udp_tunnel libblake2s blake2s_x86_64 libblake2s_generic
      curve25519_x86_64 libcurve25519_generic libchacha xfrm_interface
      xfrm6_tunnel tunnel4 veth netdevsim psample batman_adv nlmon dummy team
      bonding tls vcan ip6_gre ip6_tunnel tunnel6 gre tun ip6t_rpfilter
      ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set
      ebtable_nat ebtable_broute ip6table_nat ip6table_mangle
      ip6table_security ip6table_raw iptable_nat nf_nat nf_conntrack
      nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_security
      iptable_raw ebtable_filter ebtables rfkill ip6table_filter ip6_tables
      iptable_filter ppdev bochs drm_vram_helper drm_ttm_helper ttm
      drm_kms_helper cec parport_pc drm joydev floppy parport sg syscopyarea
      sysfillrect sysimgblt i2c_piix4 qemu_fw_cfg fb_sys_fops pcspkr
      [  343.297459]  ip_tables xfs virtio_net net_failover failover sd_mod
      sr_mod cdrom t10_pi ata_generic pata_acpi ata_piix libata virtio_pci
      virtio_pci_legacy_dev serio_raw virtio_pci_modern_dev dm_mirror
      dm_region_hash dm_log dm_mod
      [  343.311074] Dumping ftrace buffer:
      [  343.311532]    (ftrace buffer empty)
      [  343.312040] ---[ end trace a2e3db5a6ae05099 ]---
      [  343.312691] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]
      [  343.313481] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff
      ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f
      74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03
      [  343.315893] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246
      [  343.316622] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:
      0000000000000000
      [  343.317585] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:
      ffff88800f8eda40
      [  343.318549] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:
      ffffffff94fb8445
      [  343.319503] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:
      0000000000000000
      [  343.320455] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:
      0000000000000020
      [  343.321414] FS:  00007fdde2bd7700(0000) GS:ffff888109780000(0000)
      knlGS:0000000000000000
      [  343.322489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  343.323283] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:
      00000000000006e0
      [  343.324264] Kernel panic - not syncing: Fatal exception in interrupt
      [  343.333717] Dumping ftrace buffer:
      [  343.334175]    (ftrace buffer empty)
      [  343.334653] Kernel Offset: 0x13600000 from 0xffffffff81000000
      (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      [  343.336027] Rebooting in 86400 seconds..
      Reported-by: default avatarsyzkaller <syzkaller@googlegroups.com>
      Signed-off-by: default avatarHarshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
      Link: https://lore.kernel.org/r/20211129175328.55339-1-harshit.m.mogalapalli@oracle.com
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c54a60c8
    • Ondrej Jirman's avatar
      i2c: rk3x: Handle a spurious start completion interrupt flag · c69fa3b7
      Ondrej Jirman authored
      
      
      [ Upstream commit 02fe0fbd8a21e183687925c3a266ae27dda9840f ]
      
      In a typical read transfer, start completion flag is being set after
      read finishes (notice ipd bit 4 being set):
      
      trasnfer poll=0
      i2c start
      rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
      i2c read
      rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
      i2c stop
      rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 33
      
      This causes I2C transfer being aborted in polled mode from a stop completion
      handler:
      
      trasnfer poll=1
      i2c start
      rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
      i2c read
      rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 0
      rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
      i2c stop
      rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 13
      i2c stop
      rk3x-i2c fdd40000.i2c: unexpected irq in STOP: 0x10
      
      Clearing the START flag after read fixes the issue without any obvious
      side effects.
      
      This issue was dicovered on RK3566 when adding support for powering
      off the RK817 PMIC.
      Signed-off-by: default avatarOndrej Jirman <megous@megous.com>
      Reviewed-by: default avatarJohn Keeping <john@metanate.com>
      Signed-off-by: Wolfram Sang's avatarWolfram Sang <wsa@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c69fa3b7
    • Helge Deller's avatar
      parisc/agp: Annotate parisc agp init functions with __init · 3125c97a
      Helge Deller authored
      
      
      [ Upstream commit 8d88382b7436551a9ebb78475c546b670790cbf6 ]
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3125c97a
    • Tadeusz Struk's avatar
      nfc: fix segfault in nfc_genl_dump_devices_done · ea55b379
      Tadeusz Struk authored
      commit fd79a0cbf0b2e34bcc45b13acf962e2032a82203 upstream.
      
      When kmalloc in nfc_genl_dump_devices() fails then
      nfc_genl_dump_devices_done() segfaults as below
      
      KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
      CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
      Workqueue: events netlink_sock_destruct_work
      RIP: 0010:klist_iter_exit+0x26/0x80
      Call Trace:
      <TASK>
      class_dev_iter_exit+0x15/0x20
      nfc_genl_dump_devices_done+0x3b/0x50
      genl_lock_done+0x84/0xd0
      netlink_sock_destruct+0x8f/0x270
      __sk_destruct+0x64/0x3b0
      sk_destruct+0xa8/0xd0
      __sk_free+0x2e8/0x3d0
      sk_free+0x51/0x90
      netlink_sock_destruct_work+0x1c/0x20
      process_one_work+0x411/0x710
      worker_thread+0x6fd/0xa80
      
      Link: https://syzkaller.appspot.com/bug?id=fc0fa5a53db9edd261d56e74325419faf18bd0df
      
      
      Reported-by: syzbot+f9f76f4a0766420b4a02@syzkaller.appspotmail.com
      Signed-off-by: default avatarTadeusz Struk <tadeusz.struk@linaro.org>
      Reviewed-by: Krzysztof Kozłowski's avatarKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Link: https://lore.kernel.org/r/20211208182742.340542-1-tadeusz.struk@linaro.org
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea55b379
  5. 14 Dec, 2021 5 commits