1. 05 Aug, 2020 40 commits
    • Raviteja Narayanam's avatar
      Revert "i2c: cadence: Fix the hold bit setting" · 2bf308bb
      Raviteja Narayanam authored
      [ Upstream commit 0db9254d ]
      
      This reverts commit d358def7.
      
      There are two issues with "i2c: cadence: Fix the hold bit setting" commit.
      
      1. In case of combined message request from user space, when the HOLD
      bit is cleared in cdns_i2c_mrecv function, a STOP condition is sent
      on the bus even before the last message is started. This is because when
      the HOLD bit is cleared, the FIFOS are empty and there is no pending
      transfer. The STOP condition should occur only after the last message
      is completed.
      
      2. The code added by the commit is redundant. Driver is handling the
      setting/clearing of HOLD bit in right way before the commit.
      
      The setting of HOLD bit based on 'bus_hold_flag' is taken care in
      cdns_i2c_master_xfer function even before cdns_i2c_msend/cdns_i2c_recv
      functions.
      
      The clearing of HOLD bit is taken care at the end of cdns_i2c_msend and
      cdns_i2c_recv functions based on bus_hold_flag and byte count.
      Since clearing of HOLD bit is done after the slave address is written to
      the register (writing to address register triggers the message transfer),
      it is ensured that STOP condition occurs at the right time after
      completion of the pending transfer (last message).
      Signed-off-by: default avatarRaviteja Narayanam <raviteja.narayanam@xilinx.com>
      Acked-by: default avatarMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: default avatarWolfram Sang <wsa@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2bf308bb
    • Yoshihiro Shimoda's avatar
      net: ethernet: ravb: exit if re-initialization fails in tx timeout · 4418d722
      Yoshihiro Shimoda authored
      [ Upstream commit 015c5d5e ]
      
      According to the report of [1], this driver is possible to cause
      the following error in ravb_tx_timeout_work().
      
      ravb e6800000.ethernet ethernet: failed to switch device to config mode
      
      This error means that the hardware could not change the state
      from "Operation" to "Configuration" while some tx and/or rx queue
      are operating. After that, ravb_config() in ravb_dmac_init() will fail,
      and then any descriptors will be not allocaled anymore so that NULL
      pointer dereference happens after that on ravb_start_xmit().
      
      To fix the issue, the ravb_tx_timeout_work() should check
      the return values of ravb_stop_dma() and ravb_dmac_init().
      If ravb_stop_dma() fails, ravb_tx_timeout_work() re-enables TX and RX
      and just exits. If ravb_dmac_init() fails, just exits.
      
      [1]
      https://lore.kernel.org/linux-renesas-soc/20200518045452.2390-1-dirk.behme@de.bosch.com/Reported-by: default avatarDirk Behme <dirk.behme@de.bosch.com>
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Reviewed-by: default avatarSergei Shtylyov <sergei.shtylyov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4418d722
    • Liam Beguin's avatar
      parisc: add support for cmpxchg on u8 pointers · ddce1f2d
      Liam Beguin authored
      [ Upstream commit b344d6a8 ]
      
      The kernel test bot reported[1] that using set_mask_bits on a u8 causes
      the following issue on parisc:
      
      	hppa-linux-ld: drivers/phy/ti/phy-tusb1210.o: in function `tusb1210_probe':
      	>> (.text+0x2f4): undefined reference to `__cmpxchg_called_with_bad_pointer'
      	>> hppa-linux-ld: (.text+0x324): undefined reference to `__cmpxchg_called_with_bad_pointer'
      	hppa-linux-ld: (.text+0x354): undefined reference to `__cmpxchg_called_with_bad_pointer'
      
      Add support for cmpxchg on u8 pointers.
      
      [1] https://lore.kernel.org/patchwork/patch/1272617/#1468946Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarLiam Beguin <liambeguin@gmail.com>
      Tested-by: default avatarDave Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ddce1f2d
    • Navid Emamdoost's avatar
      nfc: s3fwrn5: add missing release on skb in s3fwrn5_recv_frame · 5fa5e4de
      Navid Emamdoost authored
      [ Upstream commit 1e8fd3a9 ]
      
      The implementation of s3fwrn5_recv_frame() is supposed to consume skb on
      all execution paths. Release skb before returning -ENODEV.
      Signed-off-by: default avatarNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5fa5e4de
    • Laurence Oberman's avatar
      qed: Disable "MFW indication via attention" SPAM every 5 minutes · d042d9ab
      Laurence Oberman authored
      [ Upstream commit 1d61e218 ]
      
      This is likely firmware causing this but its starting to annoy customers.
      Change the message level to verbose to prevent the spam.
      Note that this seems to only show up with ISCSI enabled on the HBA via the
      qedi driver.
      Signed-off-by: default avatarLaurence Oberman <loberman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d042d9ab
    • Geert Uytterhoeven's avatar
      usb: hso: Fix debug compile warning on sparc32 · e2ccd43b
      Geert Uytterhoeven authored
      [ Upstream commit e0484010 ]
      
      On sparc32, tcflag_t is "unsigned long", unlike on all other
      architectures, where it is "unsigned int":
      
          drivers/net/usb/hso.c: In function ‘hso_serial_set_termios’:
          include/linux/kern_levels.h:5:18: warning: format ‘%d’ expects argument of type ‘unsigned int’, but argument 4 has type ‘tcflag_t {aka long unsigned int}’ [-Wformat=]
          drivers/net/usb/hso.c:1393:3: note: in expansion of macro ‘hso_dbg’
             hso_dbg(0x16, "Termios called with: cflags new[%d] - old[%d]\n",
             ^~~~~~~
          include/linux/kern_levels.h:5:18: warning: format ‘%d’ expects argument of type ‘unsigned int’, but argument 5 has type ‘tcflag_t {aka long unsigned int}’ [-Wformat=]
          drivers/net/usb/hso.c:1393:3: note: in expansion of macro ‘hso_dbg’
             hso_dbg(0x16, "Termios called with: cflags new[%d] - old[%d]\n",
             ^~~~~~~
      
      As "unsigned long" is 32-bit on sparc32, fix this by casting all tcflag_t
      parameters to "unsigned int".
      While at it, use "%u" to format unsigned numbers.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e2ccd43b
    • Xin Xiong's avatar
      net/mlx5e: fix bpf_prog reference count leaks in mlx5e_alloc_rq · eb3a903d
      Xin Xiong authored
      [ Upstream commit e692139e ]
      
      The function invokes bpf_prog_inc(), which increases the reference
      count of a bpf_prog object "rq->xdp_prog" if the object isn't NULL.
      
      The refcount leak issues take place in two error handling paths. When
      either mlx5_wq_ll_create() or mlx5_wq_cyc_create() fails, the function
      simply returns the error code and forgets to drop the reference count
      increased earlier, causing a reference count leak of "rq->xdp_prog".
      
      Fix this issue by jumping to the error handling path err_rq_wq_destroy
      while either function fails.
      
      Fixes: 422d4c40 ("net/mlx5e: RX, Split WQ objects for different RQ types")
      Signed-off-by: default avatarXin Xiong <xiongx18@fudan.edu.cn>
      Signed-off-by: default avatarXiyu Yang <xiyuyang19@fudan.edu.cn>
      Signed-off-by: default avatarXin Tan <tanxin.ctf@gmail.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      eb3a903d
    • Wang Hai's avatar
      net: gemini: Fix missing clk_disable_unprepare() in error path of gemini_ethernet_port_probe() · 0a48de95
      Wang Hai authored
      [ Upstream commit 85496a29 ]
      
      Fix the missing clk_disable_unprepare() before return
      from gemini_ethernet_port_probe() in the error handling case.
      
      Fixes: 4d5ae32f ("net: ethernet: Add a driver for Gemini gigabit ethernet")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0a48de95
    • Alain Michaud's avatar
      Bluetooth: fix kernel oops in store_pending_adv_report · 5df9e561
      Alain Michaud authored
      [ Upstream commit a2ec905d ]
      
      Fix kernel oops observed when an ext adv data is larger than 31 bytes.
      
      This can be reproduced by setting up an advertiser with advertisement
      larger than 31 bytes.  The issue is not sensitive to the advertisement
      content.  In particular, this was reproduced with an advertisement of
      229 bytes filled with 'A'.  See stack trace below.
      
      This is fixed by not catching ext_adv as legacy adv are only cached to
      be able to concatenate a scanable adv with its scan response before
      sending it up through mgmt.
      
      With ext_adv, this is no longer necessary.
      
        general protection fault: 0000 [#1] SMP PTI
        CPU: 6 PID: 205 Comm: kworker/u17:0 Not tainted 5.4.0-37-generic #41-Ubuntu
        Hardware name: Dell Inc. XPS 15 7590/0CF6RR, BIOS 1.7.0 05/11/2020
        Workqueue: hci0 hci_rx_work [bluetooth]
        RIP: 0010:hci_bdaddr_list_lookup+0x1e/0x40 [bluetooth]
        Code: ff ff e9 26 ff ff ff 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 07 48 89 e5 48 39 c7 75 0a eb 24 48 8b 00 48 39 f8 74 1c 44 8b 06 <44> 39 40 10 75 ef 44 0f b7 4e 04 66 44 39 48 14 75 e3 38 50 16 75
        RSP: 0018:ffffbc6a40493c70 EFLAGS: 00010286
        RAX: 4141414141414141 RBX: 000000000000001b RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffff9903e76c100f RDI: ffff9904289d4b28
        RBP: ffffbc6a40493c70 R08: 0000000093570362 R09: 0000000000000000
        R10: 0000000000000000 R11: ffff9904344eae38 R12: ffff9904289d4000
        R13: 0000000000000000 R14: 00000000ffffffa3 R15: ffff9903e76c100f
        FS: 0000000000000000(0000) GS:ffff990434580000(0000) knlGS:0000000000000000
        CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00007feed125a000 CR3: 00000001b860a003 CR4: 00000000003606e0
        Call Trace:
          process_adv_report+0x12e/0x560 [bluetooth]
          hci_le_meta_evt+0x7b2/0xba0 [bluetooth]
          hci_event_packet+0x1c29/0x2a90 [bluetooth]
          hci_rx_work+0x19b/0x360 [bluetooth]
          process_one_work+0x1eb/0x3b0
          worker_thread+0x4d/0x400
          kthread+0x104/0x140
      
      Fixes: c215e939 ("Bluetooth: Process extended ADV report event")
      Reported-by: default avatarAndy Nguyen <theflow@google.com>
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: default avatarBalakrishna Godavarthi <bgodavar@codeaurora.org>
      Signed-off-by: default avatarAlain Michaud <alainm@chromium.org>
      Tested-by: default avatarSonny Sasaka <sonnysasaka@chromium.org>
      Acked-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5df9e561
    • Robin Murphy's avatar
      arm64: csum: Fix handling of bad packets · 0be9b57b
      Robin Murphy authored
      [ Upstream commit 05fb3dbd ]
      
      Although iph is expected to point to at least 20 bytes of valid memory,
      ihl may be bogus, for example on reception of a corrupt packet. If it
      happens to be less than 5, we really don't want to run away and
      dereference 16GB worth of memory until it wraps back to exactly zero...
      
      Fixes: 0e455d8e ("arm64: Implement optimised IP checksum helpers")
      Reported-by: default avatarguodeqing <geffrey.guo@huawei.com>
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0be9b57b
    • Sami Tolvanen's avatar
      arm64/alternatives: move length validation inside the subsection · 53f94177
      Sami Tolvanen authored
      [ Upstream commit 966a0acc ]
      
      Commit f7b93d42 ("arm64/alternatives: use subsections for replacement
      sequences") breaks LLVM's integrated assembler, because due to its
      one-pass design, it cannot compute instruction sequence lengths before the
      layout for the subsection has been finalized. This change fixes the build
      by moving the .org directives inside the subsection, so they are processed
      after the subsection layout is known.
      
      Fixes: f7b93d42 ("arm64/alternatives: use subsections for replacement sequences")
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Link: https://github.com/ClangBuiltLinux/linux/issues/1078
      Link: https://lore.kernel.org/r/20200730153701.3892953-1-samitolvanen@google.comSigned-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      53f94177
    • Remi Pommarel's avatar
      mac80211: mesh: Free pending skb when destroying a mpath · 0535c43d
      Remi Pommarel authored
      [ Upstream commit 5e43540c ]
      
      A mpath object can hold reference on a list of skb that are waiting for
      mpath resolution to be sent. When destroying a mpath this skb list
      should be cleaned up in order to not leak memory.
      
      Fixing that kind of leak:
      
      unreferenced object 0xffff0000181c9300 (size 1088):
        comm "openvpn", pid 1782, jiffies 4295071698 (age 80.416s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 f9 80 36 00 00 00 00 00  ..........6.....
          02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
        backtrace:
          [<000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
          [<000000002caaef13>] sk_prot_alloc.isra.39+0x34/0x178
          [<00000000ceeaa916>] sk_alloc+0x34/0x228
          [<00000000ca1f1d04>] inet_create+0x198/0x518
          [<0000000035626b1c>] __sock_create+0x134/0x328
          [<00000000a12b3a87>] __sys_socket+0xb0/0x158
          [<00000000ff859f23>] __arm64_sys_socket+0x40/0x58
          [<00000000263486ec>] el0_svc_handler+0xd0/0x1a0
          [<0000000005b5157d>] el0_svc+0x8/0xc
      unreferenced object 0xffff000012973a40 (size 216):
        comm "openvpn", pid 1782, jiffies 4295082137 (age 38.660s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 c0 06 16 00 00 ff ff 00 93 1c 18 00 00 ff ff  ................
        backtrace:
          [<000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
          [<0000000023c8c8f9>] __alloc_skb+0xc0/0x2b8
          [<000000007ad950bb>] alloc_skb_with_frags+0x60/0x320
          [<00000000ef90023a>] sock_alloc_send_pskb+0x388/0x3c0
          [<00000000104fb1a3>] sock_alloc_send_skb+0x1c/0x28
          [<000000006919d2dd>] __ip_append_data+0xba4/0x11f0
          [<0000000083477587>] ip_make_skb+0x14c/0x1a8
          [<0000000024f3d592>] udp_sendmsg+0xaf0/0xcf0
          [<000000005aabe255>] inet_sendmsg+0x5c/0x80
          [<000000008651ea08>] __sys_sendto+0x15c/0x218
          [<000000003505c99b>] __arm64_sys_sendto+0x74/0x90
          [<00000000263486ec>] el0_svc_handler+0xd0/0x1a0
          [<0000000005b5157d>] el0_svc+0x8/0xc
      
      Fixes: 2bdaf386 (mac80211: mesh: move path tables into if_mesh)
      Signed-off-by: default avatarRemi Pommarel <repk@triplefau.lt>
      Link: https://lore.kernel.org/r/20200704135419.27703-1-repk@triplefau.ltSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0535c43d
    • Remi Pommarel's avatar
      mac80211: mesh: Free ie data when leaving mesh · 37bccfa8
      Remi Pommarel authored
      [ Upstream commit 6a01afcf ]
      
      At ieee80211_join_mesh() some ie data could have been allocated (see
      copy_mesh_setup()) and need to be cleaned up when leaving the mesh.
      
      This fixes the following kmemleak report:
      
      unreferenced object 0xffff0000116bc600 (size 128):
        comm "wpa_supplicant", pid 608, jiffies 4294898983 (age 293.484s)
        hex dump (first 32 bytes):
          30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00  0...............
          00 0f ac 08 00 00 00 00 c4 65 40 00 00 00 00 00  .........e@.....
        backtrace:
          [<00000000bebe439d>] __kmalloc_track_caller+0x1c0/0x330
          [<00000000a349dbe1>] kmemdup+0x28/0x50
          [<0000000075d69baa>] ieee80211_join_mesh+0x6c/0x3b8 [mac80211]
          [<00000000683bb98b>] __cfg80211_join_mesh+0x1e8/0x4f0 [cfg80211]
          [<0000000072cb507f>] nl80211_join_mesh+0x520/0x6b8 [cfg80211]
          [<0000000077e9bcf9>] genl_family_rcv_msg+0x374/0x680
          [<00000000b1bd936d>] genl_rcv_msg+0x78/0x108
          [<0000000022c53788>] netlink_rcv_skb+0xb0/0x1c0
          [<0000000011af8ec9>] genl_rcv+0x34/0x48
          [<0000000069e41f53>] netlink_unicast+0x268/0x2e8
          [<00000000a7517316>] netlink_sendmsg+0x320/0x4c0
          [<0000000069cba205>] ____sys_sendmsg+0x354/0x3a0
          [<00000000e06bab0f>] ___sys_sendmsg+0xd8/0x120
          [<0000000037340728>] __sys_sendmsg+0xa4/0xf8
          [<000000004fed9776>] __arm64_sys_sendmsg+0x44/0x58
          [<000000001c1e5647>] el0_svc_handler+0xd0/0x1a0
      
      Fixes: c80d545d (mac80211: Let userspace enable and configure vendor specific path selection.)
      Signed-off-by: default avatarRemi Pommarel <repk@triplefau.lt>
      Link: https://lore.kernel.org/r/20200704135007.27292-1-repk@triplefau.ltSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      37bccfa8
    • Andrii Nakryiko's avatar
      bpf: Fix map leak in HASH_OF_MAPS map · 634d42ca
      Andrii Nakryiko authored
      [ Upstream commit 1d4e1eab ]
      
      Fix HASH_OF_MAPS bug of not putting inner map pointer on bpf_map_elem_update()
      operation. This is due to per-cpu extra_elems optimization, which bypassed
      free_htab_elem() logic doing proper clean ups. Make sure that inner map is put
      properly in optimized case as well.
      
      Fixes: 8c290e60 ("bpf: fix hashmap extra_elems logic")
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20200729040913.2815687-1-andriin@fb.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      634d42ca
    • Thomas Falcon's avatar
      ibmvnic: Fix IRQ mapping disposal in error path · 5858ad8d
      Thomas Falcon authored
      [ Upstream commit 27a2145d ]
      
      RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
      error paths. Fix this and dispose of TX IRQ mappings correctly in
      case of an error.
      
      Fixes: ea22d51a ("ibmvnic: simplify and improve driver probe function")
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5858ad8d
    • Ido Schimmel's avatar
      mlxsw: core: Free EMAD transactions using kfree_rcu() · 685d55c5
      Ido Schimmel authored
      [ Upstream commit 3c8ce24b ]
      
      The lifetime of EMAD transactions (i.e., 'struct mlxsw_reg_trans') is
      managed using RCU. They are freed using kfree_rcu() once the transaction
      ends.
      
      However, in case the transaction failed it is freed immediately after being
      removed from the active transactions list. This is problematic because it is
      still possible for a different CPU to dereference the transaction from an RCU
      read-side critical section while traversing the active transaction list in
      mlxsw_emad_rx_listener_func(). In which case, a use-after-free is triggered
      [1].
      
      Fix this by freeing the transaction after a grace period by calling
      kfree_rcu().
      
      [1]
      BUG: KASAN: use-after-free in mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
      Read of size 8 at addr ffff88800b7964e8 by task syz-executor.2/2881
      
      CPU: 0 PID: 2881 Comm: syz-executor.2 Not tainted 5.8.0-rc4+ #44
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xf6/0x16e lib/dump_stack.c:118
       print_address_description.constprop.0+0x1c/0x250 mm/kasan/report.c:383
       __kasan_report mm/kasan/report.c:513 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
       mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
       mlxsw_core_skb_receive+0x571/0x700 drivers/net/ethernet/mellanox/mlxsw/core.c:2061
       mlxsw_pci_cqe_rdq_handle drivers/net/ethernet/mellanox/mlxsw/pci.c:595 [inline]
       mlxsw_pci_cq_tasklet+0x12a6/0x2520 drivers/net/ethernet/mellanox/mlxsw/pci.c:651
       tasklet_action_common.isra.0+0x13f/0x3e0 kernel/softirq.c:550
       __do_softirq+0x223/0x964 kernel/softirq.c:292
       asm_call_on_stack+0x12/0x20 arch/x86/entry/entry_64.S:711
       </IRQ>
       __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
       run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
       do_softirq_own_stack+0x109/0x140 arch/x86/kernel/irq_64.c:77
       invoke_softirq kernel/softirq.c:387 [inline]
       __irq_exit_rcu kernel/softirq.c:417 [inline]
       irq_exit_rcu+0x16f/0x1a0 kernel/softirq.c:429
       sysvec_apic_timer_interrupt+0x4e/0xd0 arch/x86/kernel/apic/apic.c:1091
       asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587
      RIP: 0010:arch_local_irq_restore arch/x86/include/asm/irqflags.h:85 [inline]
      RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline]
      RIP: 0010:_raw_spin_unlock_irqrestore+0x3b/0x40 kernel/locking/spinlock.c:191
      Code: e8 2a c3 f4 fc 48 89 ef e8 12 96 f5 fc f6 c7 02 75 11 53 9d e8 d6 db 11 fd 65 ff 0d 1f 21 b3 56 5b 5d c3 e8 a7 d7 11 fd 53 9d <eb> ed 0f 1f 00 55 48 89 fd 65 ff 05 05 21 b3 56 ff 74 24 08 48 8d
      RSP: 0018:ffff8880446ffd80 EFLAGS: 00000286
      RAX: 0000000000000006 RBX: 0000000000000286 RCX: 0000000000000006
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffa94ecea9
      RBP: ffff888012934408 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000001 R11: fffffbfff57be301 R12: 1ffff110088dffc1
      R13: ffff888037b817c0 R14: ffff88802442415a R15: ffff888024424000
       __do_sys_perf_event_open+0x1b5d/0x2bd0 kernel/events/core.c:11874
       do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:384
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x473dbd
      Code: Bad RIP value.
      RSP: 002b:00007f21e5e9cc28 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
      RAX: ffffffffffffffda RBX: 000000000057bf00 RCX: 0000000000473dbd
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000040
      RBP: 000000000057bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000003 R11: 0000000000000246 R12: 000000000057bf0c
      R13: 00007ffd0493503f R14: 00000000004d0f46 R15: 00007f21e5e9cd80
      
      Allocated by task 871:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc mm/kasan/common.c:494 [inline]
       __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:467
       kmalloc include/linux/slab.h:555 [inline]
       kzalloc include/linux/slab.h:669 [inline]
       mlxsw_core_reg_access_emad+0x70/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1812
       mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
       mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
       update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
       process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
       worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
       kthread+0x355/0x470 kernel/kthread.c:291
       ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
      
      Freed by task 871:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       kasan_set_free_info mm/kasan/common.c:316 [inline]
       __kasan_slab_free+0x12c/0x170 mm/kasan/common.c:455
       slab_free_hook mm/slub.c:1474 [inline]
       slab_free_freelist_hook mm/slub.c:1507 [inline]
       slab_free mm/slub.c:3072 [inline]
       kfree+0xe6/0x320 mm/slub.c:4052
       mlxsw_core_reg_access_emad+0xd45/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1819
       mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
       mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
       update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
       process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
       worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
       kthread+0x355/0x470 kernel/kthread.c:291
       ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
      
      The buggy address belongs to the object at ffff88800b796400
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 232 bytes inside of
       512-byte region [ffff88800b796400, ffff88800b796600)
      The buggy address belongs to the page:
      page:ffffea00002de500 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 head:ffffea00002de500 order:2 compound_mapcount:0 compound_pincount:0
      flags: 0x100000000010200(slab|head)
      raw: 0100000000010200 dead000000000100 dead000000000122 ffff88806c402500
      raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88800b796380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88800b796400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff88800b796480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                ^
       ffff88800b796500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88800b796580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: caf7297e ("mlxsw: core: Introduce support for asynchronous EMAD register access")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      685d55c5
    • Ido Schimmel's avatar
      mlxsw: core: Increase scope of RCU read-side critical section · b7935969
      Ido Schimmel authored
      [ Upstream commit 7d8e8f34 ]
      
      The lifetime of the Rx listener item ('rxl_item') is managed using RCU,
      but is dereferenced outside of RCU read-side critical section, which can
      lead to a use-after-free.
      
      Fix this by increasing the scope of the RCU read-side critical section.
      
      Fixes: 93c1edb2 ("mlxsw: Introduce Mellanox switch driver core")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b7935969
    • Jakub Kicinski's avatar
      mlx4: disable device on shutdown · 111462ba
      Jakub Kicinski authored
      [ Upstream commit 3cab8c65 ]
      
      It appears that not disabling a PCI device on .shutdown may lead to
      a Hardware Error with particular (perhaps buggy) BIOS versions:
      
          mlx4_en: eth0: Close port called
          mlx4_en 0000:04:00.0: removed PHC
          reboot: Restarting system
          {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
          {1}[Hardware Error]: event severity: fatal
          {1}[Hardware Error]:  Error 0, type: fatal
          {1}[Hardware Error]:   section_type: PCIe error
          {1}[Hardware Error]:   port_type: 4, root port
          {1}[Hardware Error]:   version: 1.16
          {1}[Hardware Error]:   command: 0x4010, status: 0x0143
          {1}[Hardware Error]:   device_id: 0000:00:02.2
          {1}[Hardware Error]:   slot: 0
          {1}[Hardware Error]:   secondary_bus: 0x04
          {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2f06
          {1}[Hardware Error]:   class_code: 000604
          {1}[Hardware Error]:   bridge: secondary_status: 0x2000, control: 0x0003
          {1}[Hardware Error]:   aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00000000
          {1}[Hardware Error]:   aer_uncor_severity: 0x00062030
          {1}[Hardware Error]:   TLP Header: 40000018 040000ff 791f4080 00000000
      [hw error repeats]
          Kernel panic - not syncing: Fatal hardware error!
          CPU: 0 PID: 2189 Comm: reboot Kdump: loaded Not tainted 5.6.x-blabla #1
          Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 05/05/2017
      
      Fix the mlx4 driver.
      
      This is a very similar problem to what had been fixed in:
      commit 0d98ba8d ("scsi: hpsa: disable device during shutdown")
      to address https://bugzilla.kernel.org/show_bug.cgi?id=199779.
      
      Fixes: 2ba5fbd6 ("net/mlx4_core: Handle AER flow properly")
      Reported-by: default avatarJake Lawrence <lawja@fb.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      111462ba
    • Johan Hovold's avatar
      net: lan78xx: fix transfer-buffer memory leak · ff94414f
      Johan Hovold authored
      [ Upstream commit 63634aa6 ]
      
      The interrupt URB transfer-buffer was never freed on disconnect or after
      probe errors.
      
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
      Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ff94414f
    • Johan Hovold's avatar
      net: lan78xx: add missing endpoint sanity check · 3c1add35
      Johan Hovold authored
      [ Upstream commit 8d8e95fd ]
      
      Add the missing endpoint sanity check to prevent a NULL-pointer
      dereference should a malicious device lack the expected endpoints.
      
      Note that the driver has a broken endpoint-lookup helper,
      lan78xx_get_endpoints(), which can end up accepting interfaces in an
      altsetting without endpoints as long as *some* altsetting has a bulk-in
      and a bulk-out endpoint.
      
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
      Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3c1add35
    • Eran Ben Elisha's avatar
      net/mlx5: Verify Hardware supports requested ptp function on a given pin · ee9599af
      Eran Ben Elisha authored
      [ Upstream commit 071995c8 ]
      
      Fix a bug where driver did not verify Hardware pin capabilities for
      PTP functions.
      
      Fixes: ee7f1220 ("net/mlx5e: Implement 1PPS support")
      Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Reviewed-by: default avatarAriel Levkovich <lariel@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ee9599af
    • Michael Karcher's avatar
      sh: Fix validation of system call number · 93bfba81
      Michael Karcher authored
      [ Upstream commit 04a8a3d0 ]
      
      The slow path for traced system call entries accessed a wrong memory
      location to get the number of the maximum allowed system call number.
      Renumber the numbered "local" label for the correct location to avoid
      collisions with actual local labels.
      Signed-off-by: default avatarMichael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
      Tested-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Fixes: f3a83088 ("sh: Add a few missing irqflags tracing markers.")
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      93bfba81
    • Tanner Love's avatar
      selftests/net: psock_fanout: fix clang issues for target arch PowerPC · 7846460c
      Tanner Love authored
      [ Upstream commit 64f9ede2 ]
      
      Clang 9 threw:
      warning: format specifies type 'unsigned short' but the argument has \
      type 'int' [-Wformat]
                      typeflags, PORT_BASE, PORT_BASE + port_off);
      
      Tested: make -C tools/testing/selftests TARGETS="net" run_tests
      
      Fixes: 77f65ebd ("packet: packet fanout rollover during socket overload")
      Signed-off-by: default avatarTanner Love <tannerlove@google.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7846460c
    • Tanner Love's avatar
      selftests/net: rxtimestamp: fix clang issues for target arch PowerPC · fbd97d5b
      Tanner Love authored
      [ Upstream commit 955cbe91 ]
      
      The signedness of char is implementation-dependent. Some systems
      (including PowerPC and ARM) use unsigned char. Clang 9 threw:
      warning: result of comparison of constant -1 with expression of type \
      'char' is always true [-Wtautological-constant-out-of-range-compare]
                                        &arg_index)) != -1) {
      
      Tested: make -C tools/testing/selftests TARGETS="net" run_tests
      
      Fixes: 16e78122 ("selftests/net: Add a test to validate behavior of rx timestamps")
      Signed-off-by: default avatarTanner Love <tannerlove@google.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fbd97d5b
    • Steffen Klassert's avatar
      xfrm: Fix crash when the hold queue is used. · 8b2a6581
      Steffen Klassert authored
      [ Upstream commit 101dde42 ]
      
      The commits "xfrm: Move dst->path into struct xfrm_dst"
      and "net: Create and use new helper xfrm_dst_child()."
      changed xfrm bundle handling under the assumption
      that xdst->path and dst->child are not a NULL pointer
      only if dst->xfrm is not a NULL pointer. That is true
      with one exception. If the xfrm hold queue is used
      to wait until a SA is installed by the key manager,
      we create a dummy bundle without a valid dst->xfrm
      pointer. The current xfrm bundle handling crashes
      in that case. Fix this by extending the NULL check
      of dst->xfrm with a test of the DST_XFRM_QUEUE flag.
      
      Fixes: 0f6c480f ("xfrm: Move dst->path into struct xfrm_dst")
      Fixes: b92cf4aa ("net: Create and use new helper xfrm_dst_child().")
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8b2a6581
    • YueHaibing's avatar
      net/x25: Fix null-ptr-deref in x25_disconnect · 9a5e3aba
      YueHaibing authored
      commit 8999dc89 upstream.
      
      We should check null before do x25_neigh_put in x25_disconnect,
      otherwise may cause null-ptr-deref like this:
      
       #include <sys/socket.h>
       #include <linux/x25.h>
      
       int main() {
          int sck_x25;
          sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0);
          close(sck_x25);
          return 0;
       }
      
      BUG: kernel NULL pointer dereference, address: 00000000000000d8
      CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-
      RIP: 0010:x25_disconnect+0x91/0xe0
      Call Trace:
       x25_release+0x18a/0x1b0
       __sock_release+0x3d/0xc0
       sock_close+0x13/0x20
       __fput+0x107/0x270
       ____fput+0x9/0x10
       task_work_run+0x6d/0xb0
       exit_to_usermode_loop+0x102/0x110
       do_syscall_64+0x23c/0x260
       entry_SYSCALL_64_after_hwframe+0x49/0xb3
      
      Reported-by: syzbot+6db548b615e5aeefdce2@syzkaller.appspotmail.com
      Fixes: 4becb7ee ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9a5e3aba
    • Xiyu Yang's avatar
      net/x25: Fix x25_neigh refcnt leak when x25 disconnect · fca9ee21
      Xiyu Yang authored
      commit 4becb7ee upstream.
      
      x25_connect() invokes x25_get_neigh(), which returns a reference of the
      specified x25_neigh object to "x25->neighbour" with increased refcnt.
      
      When x25 connect success and returns, the reference still be hold by
      "x25->neighbour", so the refcount should be decreased in
      x25_disconnect() to keep refcount balanced.
      
      The reference counting issue happens in x25_disconnect(), which forgets
      to decrease the refcnt increased by x25_get_neigh() in x25_connect(),
      causing a refcnt leak.
      
      Fix this issue by calling x25_neigh_put() before x25_disconnect()
      returns.
      Signed-off-by: default avatarXiyu Yang <xiyuyang19@fudan.edu.cn>
      Signed-off-by: default avatarXin Tan <tanxin.ctf@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fca9ee21
    • Rik van Riel's avatar
      xfs: fix missed wakeup on l_flush_wait · ab629183
      Rik van Riel authored
      commit cdea5459 upstream.
      
      The code in xlog_wait uses the spinlock to make adding the task to
      the wait queue, and setting the task state to UNINTERRUPTIBLE atomic
      with respect to the waker.
      
      Doing the wakeup after releasing the spinlock opens up the following
      race condition:
      
      Task 1					task 2
      add task to wait queue
      					wake up task
      set task state to UNINTERRUPTIBLE
      
      This issue was found through code inspection as a result of kworkers
      being observed stuck in UNINTERRUPTIBLE state with an empty
      wait queue. It is rare and largely unreproducable.
      
      Simply moving the spin_unlock to after the wake_up_all results
      in the waker not being able to see a task on the waitqueue before
      it has set its state to UNINTERRUPTIBLE.
      
      This bug dates back to the conversion of this code to generic
      waitqueue infrastructure from a counting semaphore back in 2008
      which didn't place the wakeups consistently w.r.t. to the relevant
      spin locks.
      
      [dchinner: Also fix a similar issue in the shutdown path on
      xc_commit_wait. Update commit log with more details of the issue.]
      
      Fixes: d748c623 ("[XFS] Convert l_flushsema to a sv_t")
      Reported-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarRik van Riel <riel@surriel.com>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Cc: stable@vger.kernel.org # 4.9.x-4.19.x
      [modified for contextual change near xlog_state_do_callback()]
      Signed-off-by: default avatarSamuel Mendoza-Jonas <samjonas@amazon.com>
      Reviewed-by: default avatarFrank van der Linden <fllinden@amazon.com>
      Reviewed-by: default avatarSuraj Jitindar Singh <surajjs@amazon.com>
      Reviewed-by: default avatarBenjamin Herrenschmidt <benh@amazon.com>
      Reviewed-by: default avatarAnchal Agarwal <anchalag@amazon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab629183
    • Peilin Ye's avatar
      rds: Prevent kernel-infoleak in rds_notify_queue_get() · 24578a23
      Peilin Ye authored
      commit bbc8a99e upstream.
      
      rds_notify_queue_get() is potentially copying uninitialized kernel stack
      memory to userspace since the compiler may leave a 4-byte hole at the end
      of `cmsg`.
      
      In 2016 we tried to fix this issue by doing `= { 0 };` on `cmsg`, which
      unfortunately does not always initialize that 4-byte hole. Fix it by using
      memset() instead.
      
      Cc: stable@vger.kernel.org
      Fixes: f037590f ("rds: fix a leak of kernel memory")
      Fixes: bdbe6fbc ("RDS: recv.c")
      Suggested-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarPeilin Ye <yepeilin.cs@gmail.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24578a23
    • Steve Cohen's avatar
      drm: hold gem reference until object is no longer accessed · 80512b95
      Steve Cohen authored
      commit 8490d6a7 upstream.
      
      A use-after-free in drm_gem_open_ioctl can happen if the
      GEM object handle is closed between the idr lookup and
      retrieving the size from said object since a local reference
      is not being held at that point. Hold the local reference
      while the object can still be accessed to fix this and
      plug the potential security hole.
      Signed-off-by: default avatarSteve Cohen <cohens@codeaurora.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1595284250-31580-1-git-send-email-cohens@codeaurora.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80512b95
    • Peilin Ye's avatar
      drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl() · 5febb6f9
      Peilin Ye authored
      commit 543e8669 upstream.
      
      Compiler leaves a 4-byte hole near the end of `dev_info`, causing
      amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
      when `size` is greater than 356.
      
      In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
      unfortunately does not initialize that 4-byte hole. Fix it by using
      memset() instead.
      
      Cc: stable@vger.kernel.org
      Fixes: c193fa91 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
      Fixes: d38ceaf9 ("drm/amdgpu: add core driver (v4)")
      Suggested-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarPeilin Ye <yepeilin.cs@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5febb6f9
    • Alex Deucher's avatar
      Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers" · 7b88c1ef
      Alex Deucher authored
      commit 87004abf upstream.
      
      This regressed some working configurations so revert it.  Will
      fix this properly for 5.9 and backport then.
      
      This reverts commit 38e0c89a.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b88c1ef
    • Will Deacon's avatar
      ARM: 8986/1: hw_breakpoint: Don't invoke overflow handler on uaccess watchpoints · 2fdddd59
      Will Deacon authored
      commit eec13b42 upstream.
      
      Unprivileged memory accesses generated by the so-called "translated"
      instructions (e.g. LDRT) in kernel mode can cause user watchpoints to fire
      unexpectedly. In such cases, the hw_breakpoint logic will invoke the user
      overflow handler which will typically raise a SIGTRAP back to the current
      task. This is futile when returning back to the kernel because (a) the
      signal won't have been delivered and (b) userspace can't handle the thing
      anyway.
      
      Avoid invoking the user overflow handler for watchpoints triggered by
      kernel uaccess routines, and instead single-step over the faulting
      instruction as we would if no overflow handler had been installed.
      
      Cc: <stable@vger.kernel.org>
      Fixes: f81ef4a9 ("ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework")
      Reported-by: default avatarLuis Machado <luis.machado@linaro.org>
      Tested-by: default avatarLuis Machado <luis.machado@linaro.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2fdddd59
    • Pi-Hsun Shih's avatar
      wireless: Use offsetof instead of custom macro. · 8eff5a05
      Pi-Hsun Shih authored
      commit 6989310f upstream.
      
      Use offsetof to calculate offset of a field to take advantage of
      compiler built-in version when possible, and avoid UBSAN warning when
      compiling with Clang:
      
      ==================================================================
      UBSAN: Undefined behaviour in net/wireless/wext-core.c:525:14
      member access within null pointer of type 'struct iw_point'
      CPU: 3 PID: 165 Comm: kworker/u16:3 Tainted: G S      W         4.19.23 #43
      Workqueue: cfg80211 __cfg80211_scan_done [cfg80211]
      Call trace:
       dump_backtrace+0x0/0x194
       show_stack+0x20/0x2c
       __dump_stack+0x20/0x28
       dump_stack+0x70/0x94
       ubsan_epilogue+0x14/0x44
       ubsan_type_mismatch_common+0xf4/0xfc
       __ubsan_handle_type_mismatch_v1+0x34/0x54
       wireless_send_event+0x3cc/0x470
       ___cfg80211_scan_done+0x13c/0x220 [cfg80211]
       __cfg80211_scan_done+0x28/0x34 [cfg80211]
       process_one_work+0x170/0x35c
       worker_thread+0x254/0x380
       kthread+0x13c/0x158
       ret_from_fork+0x10/0x18
      ===================================================================
      Signed-off-by: default avatarPi-Hsun Shih <pihsun@chromium.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Link: https://lore.kernel.org/r/20191204081307.138765-1-pihsun@chromium.orgSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8eff5a05
    • Wang Hai's avatar
      9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work · 7271d032
      Wang Hai authored
      commit 74d6a5d5 upstream.
      
      p9_read_work and p9_fd_cancelled may be called concurrently.
      In some cases, req->req_list may be deleted by both p9_read_work
      and p9_fd_cancelled.
      
      We can fix it by ignoring replies associated with a cancelled
      request and ignoring cancelled request if message has been received
      before lock.
      
      Link: http://lkml.kernel.org/r/20200612090833.36149-1-wanghai38@huawei.com
      Fixes: 60ff779c ("9p: client: remove unused code and any reference to "cancelled" function")
      Cc: <stable@vger.kernel.org> # v3.12+
      Reported-by: syzbot+77a25acfa0382e06ab23@syzkaller.appspotmail.com
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Signed-off-by: default avatarDominique Martinet <asmadeus@codewreck.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7271d032
    • Robert Hancock's avatar
      PCI/ASPM: Disable ASPM on ASMedia ASM1083/1085 PCIe-to-PCI bridge · 80c1e18c
      Robert Hancock authored
      commit b361663c upstream.
      
      Recently ASPM handling was changed to allow ASPM on PCIe-to-PCI/PCI-X
      bridges.  Unfortunately the ASMedia ASM1083/1085 PCIe to PCI bridge device
      doesn't seem to function properly with ASPM enabled.  On an Asus PRIME
      H270-PRO motherboard, it causes errors like these:
      
        pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
        pcieport 0000:00:1c.0: AER:   device [8086:a292] error status/mask=00003000/00002000
        pcieport 0000:00:1c.0: AER:    [12] Timeout
        pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0
        pcieport 0000:00:1c.0: AER: can't find device of ID00e0
      
      In addition to flooding the kernel log, this also causes the machine to
      wake up immediately after suspend is initiated.
      
      The device advertises ASPM L0s and L1 support in the Link Capabilities
      register, but the ASMedia web page for ASM1083 [1] claims "No PCIe ASPM
      support".
      
      Windows 10 (build 2004) enables L0s, but it also logs correctable PCIe
      errors.
      
      Add a quirk to disable ASPM for this device.
      
      [1] https://www.asmedia.com.tw/eng/e_show_products.php?cate_index=169&item=114
      
      [bhelgaas: commit log]
      Fixes: 66ff14e5 ("PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208667
      Link: https://lore.kernel.org/r/20200722021803.17958-1-hancockrwd@gmail.comSigned-off-by: default avatarRobert Hancock <hancockrwd@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80c1e18c
    • Filipe Manana's avatar
      Btrfs: fix selftests failure due to uninitialized i_mode in test inodes · cd823ab5
      Filipe Manana authored
      [ Upstream commit 9f7fec0b ]
      
      Some of the self tests create a test inode, setup some extents and then do
      calls to btrfs_get_extent() to test that the corresponding extent maps
      exist and are correct. However btrfs_get_extent(), since the 5.2 merge
      window, now errors out when it finds a regular or prealloc extent for an
      inode that does not correspond to a regular file (its ->i_mode is not
      S_IFREG). This causes the self tests to fail sometimes, specially when
      KASAN, slub_debug and page poisoning are enabled:
      
        $ modprobe btrfs
        modprobe: ERROR: could not insert 'btrfs': Invalid argument
      
        $ dmesg
        [ 9414.691648] Btrfs loaded, crc32c=crc32c-intel, debug=on, assert=on, integrity-checker=on, ref-verify=on
        [ 9414.692655] BTRFS: selftest: sectorsize: 4096  nodesize: 4096
        [ 9414.692658] BTRFS: selftest: running btrfs free space cache tests
        [ 9414.692918] BTRFS: selftest: running extent only tests
        [ 9414.693061] BTRFS: selftest: running bitmap only tests
        [ 9414.693366] BTRFS: selftest: running bitmap and extent tests
        [ 9414.696455] BTRFS: selftest: running space stealing from bitmap to extent tests
        [ 9414.697131] BTRFS: selftest: running extent buffer operation tests
        [ 9414.697133] BTRFS: selftest: running btrfs_split_item tests
        [ 9414.697564] BTRFS: selftest: running extent I/O tests
        [ 9414.697583] BTRFS: selftest: running find delalloc tests
        [ 9415.081125] BTRFS: selftest: running find_first_clear_extent_bit test
        [ 9415.081278] BTRFS: selftest: running extent buffer bitmap tests
        [ 9415.124192] BTRFS: selftest: running inode tests
        [ 9415.124195] BTRFS: selftest: running btrfs_get_extent tests
        [ 9415.127909] BTRFS: selftest: running hole first btrfs_get_extent test
        [ 9415.128343] BTRFS critical (device (efault)): regular/prealloc extent found for non-regular inode 256
        [ 9415.131428] BTRFS: selftest: fs/btrfs/tests/inode-tests.c:904 expected a real extent, got 0
      
      This happens because the test inodes are created without ever initializing
      the i_mode field of the inode, and neither VFS's new_inode() nor the btrfs
      callback btrfs_alloc_inode() initialize the i_mode. Initialization of the
      i_mode is done through the various callbacks used by the VFS to create
      new inodes (regular files, directories, symlinks, tmpfiles, etc), which
      all call btrfs_new_inode() which in turn calls inode_init_owner(), which
      sets the inode's i_mode. Since the tests only uses new_inode() to create
      the test inodes, the i_mode was never initialized.
      
      This always happens on a VM I used with kasan, slub_debug and many other
      debug facilities enabled. It also happened to someone who reported this
      on bugzilla (on a 5.3-rc).
      
      Fix this by setting i_mode to S_IFREG at btrfs_new_test_inode().
      
      Fixes: 6bf9e4bd ("btrfs: inode: Verify inode mode to avoid NULL pointer dereference")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204397Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cd823ab5
    • Xin Long's avatar
      sctp: implement memory accounting on tx path · 9a84bb13
      Xin Long authored
      [ Upstream commit 1033990a ]
      
      Now when sending packets, sk_mem_charge() and sk_mem_uncharge() have been
      used to set sk_forward_alloc. We just need to call sk_wmem_schedule() to
      check if the allocated should be raised, and call sk_mem_reclaim() to
      check if the allocated should be reduced when it's under memory pressure.
      
      If sk_wmem_schedule() returns false, which means no memory is allowed to
      allocate, it will block and wait for memory to become available.
      
      Note different from tcp, sctp wait_for_buf happens before allocating any
      skb, so memory accounting check is done with the whole msg_len before it
      too.
      Reported-by: default avatarMatteo Croce <mcroce@redhat.com>
      Tested-by: default avatarMatteo Croce <mcroce@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9a84bb13
    • Qu Wenruo's avatar
      btrfs: inode: Verify inode mode to avoid NULL pointer dereference · 4e986ab3
      Qu Wenruo authored
      [ Upstream commit 6bf9e4bd ]
      
      [BUG]
      When accessing a file on a crafted image, btrfs can crash in block layer:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
        PGD 136501067 P4D 136501067 PUD 124519067 PMD 0
        CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.0.0-rc8-default #252
        RIP: 0010:end_bio_extent_readpage+0x144/0x700
        Call Trace:
         <IRQ>
         blk_update_request+0x8f/0x350
         blk_mq_end_request+0x1a/0x120
         blk_done_softirq+0x99/0xc0
         __do_softirq+0xc7/0x467
         irq_exit+0xd1/0xe0
         call_function_single_interrupt+0xf/0x20
         </IRQ>
        RIP: 0010:default_idle+0x1e/0x170
      
      [CAUSE]
      The crafted image has a tricky corruption, the INODE_ITEM has a
      different type against its parent dir:
      
              item 20 key (268 INODE_ITEM 0) itemoff 2808 itemsize 160
                      generation 13 transid 13 size 1048576 nbytes 1048576
                      block group 0 mode 121644 links 1 uid 0 gid 0 rdev 0
                      sequence 9 flags 0x0(none)
      
      This mode number 0120000 means it's a symlink.
      
      But the dir item think it's still a regular file:
      
              item 8 key (264 DIR_INDEX 5) itemoff 3707 itemsize 32
                      location key (268 INODE_ITEM 0) type FILE
                      transid 13 data_len 0 name_len 2
                      name: f4
              item 40 key (264 DIR_ITEM 51821248) itemoff 1573 itemsize 32
                      location key (268 INODE_ITEM 0) type FILE
                      transid 13 data_len 0 name_len 2
                      name: f4
      
      For symlink, we don't set BTRFS_I(inode)->io_tree.ops and leave it
      empty, as symlink is only designed to have inlined extent, all handled
      by tree block read.  Thus no need to trigger btrfs_submit_bio_hook() for
      inline file extent.
      
      However end_bio_extent_readpage() expects tree->ops populated, as it's
      reading regular data extent.  This causes NULL pointer dereference.
      
      [FIX]
      This patch fixes the problem in two ways:
      
      - Verify inode mode against its dir item when looking up inode
        So in btrfs_lookup_dentry() if we find inode mode mismatch with dir
        item, we error out so that corrupted inode will not be accessed.
      
      - Verify inode mode when getting extent mapping
        Only regular file should have regular or preallocated extent.
        If we found regular/preallocated file extent for symlink or
        the rest, we error out before submitting the read bio.
      
      With this fix that crafted image can be rejected gracefully:
      
        BTRFS critical (device loop0): inode mode mismatch with dir: inode mode=0121644 btrfs type=7 dir type=1
      Reported-by: default avatarYoon Jungyeon <jungyeon@gatech.edu>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=202763Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarQu Wenruo <wqu@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4e986ab3
    • Navid Emamdoost's avatar
      drm/amd/display: prevent memory leak · 60e1b411
      Navid Emamdoost authored
      [ Upstream commit 104c3071 ]
      
      In dcn*_create_resource_pool the allocated memory should be released if
      construct pool fails.
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      60e1b411