1. 25 Aug, 2019 40 commits
    • Anders Roxell's avatar
      arm64: KVM: regmap: Fix unexpected switch fall-through · c8d95668
      Anders Roxell authored
      commit 3d584a3c upstream.
      
      When fall-through warnings was enabled by default, commit d93512ef0f0e
      ("Makefile: Globally enable fall-through warning"), the following
      warnings was starting to show up:
      
      In file included from ../arch/arm64/include/asm/kvm_emulate.h:19,
                       from ../arch/arm64/kvm/regmap.c:13:
      ../arch/arm64/kvm/regmap.c: In function ‘vcpu_write_spsr32’:
      ../arch/arm64/include/asm/kvm_hyp.h:31:3: warning: this statement may fall
       through [-Wimplicit-fallthrough=]
         asm volatile(ALTERNATIVE(__msr_s(r##nvh, "%x0"), \
         ^~~
      ../arch/arm64/include/asm/kvm_hyp.h:46:31: note: in expansion of macro ‘write_sysreg_elx’
       #define write_sysreg_el1(v,r) write_sysreg_elx(v, r, _EL1, _EL12)
                                     ^~~~~~~~~~~~~~~~
      ../arch/arm64/kvm/regmap.c:180:3: note: in expansion of macro ‘write_sysreg_el1’
         write_sysreg_el1(v, SYS_SPSR);
         ^~~~~~~~~~~~~~~~
      ../arch/arm64/kvm/regmap.c:181:2: note: here
        case KVM_SPSR_ABT:
        ^~~~
      In file included from ../arch/arm64/include/asm/cputype.h:132,
                       from ../arch/arm64/include/asm/cache.h:8,
                       from ../include/linux/cache.h:6,
                       from ../include/linux/printk.h:9,
                       from ../include/linux/kernel.h:15,
                       from ../include/asm-generic/bug.h:18,
                       from ../arch/arm64/include/asm/bug.h:26,
                       from ../include/linux/bug.h:5,
                       from ../include/linux/mmdebug.h:5,
                       from ../include/linux/mm.h:9,
                       from ../arch/arm64/kvm/regmap.c:11:
      ../arch/arm64/include/asm/sysreg.h:837:2: warning: this statement may fall
       through [-Wimplicit-fallthrough=]
        asm volatile("msr " __stringify(r) ", %x0"  \
        ^~~
      ../arch/arm64/kvm/regmap.c:182:3: note: in expansion of macro ‘write_sysreg’
         write_sysreg(v, spsr_abt);
         ^~~~~~~~~~~~
      ../arch/arm64/kvm/regmap.c:183:2: note: here
        case KVM_SPSR_UND:
        ^~~~
      
      Rework to add a 'break;' in the swich-case since it didn't have that,
      leading to an interresting set of bugs.
      
      Cc: stable@vger.kernel.org # v4.17+
      Fixes: a8928195 ("KVM: arm64: Prepare to handle deferred save/restore of 32-bit registers")
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      [maz: reworked commit message, fixed stable range]
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      c8d95668
    • Qian Cai's avatar
      asm-generic: fix -Wtype-limits compiler warnings · 0755b6b1
      Qian Cai authored
      [ Upstream commit cbedfe11 ]
      
      Commit d66acc39 ("bitops: Optimise get_order()") introduced a
      compilation warning because "rx_frag_size" is an "ushort" while
      PAGE_SHIFT here is 16.
      
      The commit changed the get_order() to be a multi-line macro where
      compilers insist to check all statements in the macro even when
      __builtin_constant_p(rx_frag_size) will return false as "rx_frag_size"
      is a module parameter.
      
      In file included from ./arch/powerpc/include/asm/page_64.h:107,
                       from ./arch/powerpc/include/asm/page.h:242,
                       from ./arch/powerpc/include/asm/mmu.h:132,
                       from ./arch/powerpc/include/asm/lppaca.h:47,
                       from ./arch/powerpc/include/asm/paca.h:17,
                       from ./arch/powerpc/include/asm/current.h:13,
                       from ./include/linux/thread_info.h:21,
                       from ./arch/powerpc/include/asm/processor.h:39,
                       from ./include/linux/prefetch.h:15,
                       from drivers/net/ethernet/emulex/benet/be_main.c:14:
      drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_rx_cqs_create':
      ./include/asm-generic/getorder.h:54:9: warning: comparison is always
      true due to limited range of data type [-Wtype-limits]
         (((n) < (1UL << PAGE_SHIFT)) ? 0 :  \
               ^
      drivers/net/ethernet/emulex/benet/be_main.c:3138:33: note: in expansion
      of macro 'get_order'
        adapter->big_page_size = (1 << get_order(rx_frag_size)) * PAGE_SIZE;
                                       ^~~~~~~~~
      
      Fix it by moving all of this multi-line macro into a proper function,
      and killing __get_order() off.
      
      [akpm@linux-foundation.org: remove __get_order() altogether]
      [cai@lca.pw: v2]
        Link: http://lkml.kernel.org/r/1564000166-31428-1-git-send-email-cai@lca.pw
      Link: http://lkml.kernel.org/r/1563914986-26502-1-git-send-email-cai@lca.pw
      Fixes: d66acc39 ("bitops: Optimise get_order()")
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Bill Wendling <morbo@google.com>
      Cc: James Y Knight <jyknight@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0755b6b1
    • YueHaibing's avatar
      ocfs2: remove set but not used variable 'last_hash' · 7113a1bc
      YueHaibing authored
      [ Upstream commit 7bc36e3c ]
      
      Fixes gcc '-Wunused-but-set-variable' warning:
      
        fs/ocfs2/xattr.c: In function ocfs2_xattr_bucket_find:
        fs/ocfs2/xattr.c:3828:6: warning: variable last_hash set but not used [-Wunused-but-set-variable]
      
      It's never used and can be removed.
      
      Link: http://lkml.kernel.org/r/20190716132110.34836-1-yuehaibing@huawei.comSigned-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Cc: Gang He <ghe@suse.com>
      Cc: Jun Piao <piaojun@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7113a1bc
    • Yang Shi's avatar
      Revert "kmemleak: allow to coexist with fault injection" · 01d8d08f
      Yang Shi authored
      [ Upstream commit df9576de ]
      
      When running ltp's oom test with kmemleak enabled, the below warning was
      triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
      passed in:
      
        WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608 __alloc_pages_nodemask+0x1c31/0x1d50
        Modules linked in: loop dax_pmem dax_pmem_core ip_tables x_tables xfs virtio_net net_failover virtio_blk failover ata_generic virtio_pci virtio_ring virtio libata
        CPU: 105 PID: 2138 Comm: oom01 Not tainted 5.2.0-next-20190710+ #7
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
        RIP: 0010:__alloc_pages_nodemask+0x1c31/0x1d50
        ...
         kmemleak_alloc+0x4e/0xb0
         kmem_cache_alloc+0x2a7/0x3e0
         mempool_alloc_slab+0x2d/0x40
         mempool_alloc+0x118/0x2b0
         bio_alloc_bioset+0x19d/0x350
         get_swap_bio+0x80/0x230
         __swap_writepage+0x5ff/0xb20
      
      The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, however kmemleak
      has __GFP_NOFAIL set all the time due to d9570ee3 ("kmemleak:
      allow to coexist with fault injection").  But, it doesn't make any sense
      to have __GFP_NOFAIL and ~__GFP_DIRECT_RECLAIM specified at the same
      time.
      
      According to the discussion on the mailing list, the commit should be
      reverted for short term solution.  Catalin Marinas would follow up with
      a better solution for longer term.
      
      The failure rate of kmemleak metadata allocation may increase in some
      circumstances, but this should be expected side effect.
      
      Link: http://lkml.kernel.org/r/1563299431-111710-1-git-send-email-yang.shi@linux.alibaba.com
      Fixes: d9570ee3 ("kmemleak: allow to coexist with fault injection")
      Signed-off-by: default avatarYang Shi <yang.shi@linux.alibaba.com>
      Suggested-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Qian Cai <cai@lca.pw>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      01d8d08f
    • Colin Ian King's avatar
      drm/exynos: fix missing decrement of retry counter · cf9a18d7
      Colin Ian King authored
      [ Upstream commit 1bbbab09 ]
      
      Currently the retry counter is not being decremented, leading to a
      potential infinite spin if the scalar_reads don't change state.
      
      Addresses-Coverity: ("Infinite loop")
      Fixes: 280e54c9 ("drm/exynos: scaler: Reset hardware before starting the operation")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cf9a18d7
    • Jeffrey Hugo's avatar
      drm: msm: Fix add_gpu_components · c256729f
      Jeffrey Hugo authored
      [ Upstream commit 9ca7ad6c ]
      
      add_gpu_components() adds found GPU nodes from the DT to the match list,
      regardless of the status of the nodes.  This is a problem, because if the
      nodes are disabled, they should not be on the match list because they will
      not be matched.  This prevents display from initing if a GPU node is
      defined, but it's status is disabled.
      
      Fix this by checking the node's status before adding it to the match list.
      
      Fixes: dc3ea265 (drm/msm: Drop the gpu binding)
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarJeffrey Hugo <jeffrey.l.hugo@gmail.com>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190626180015.45242-1-jeffrey.l.hugo@gmail.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      c256729f
    • Jack Morgenstein's avatar
      IB/mad: Fix use-after-free in ib mad completion handling · b4f0fee7
      Jack Morgenstein authored
      [ Upstream commit 770b7d96 ]
      
      We encountered a use-after-free bug when unloading the driver:
      
      [ 3562.116059] BUG: KASAN: use-after-free in ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.117233] Read of size 4 at addr ffff8882ca5aa868 by task kworker/u13:2/23862
      [ 3562.118385]
      [ 3562.119519] CPU: 2 PID: 23862 Comm: kworker/u13:2 Tainted: G           OE     5.1.0-for-upstream-dbg-2019-05-19_16-44-30-13 #1
      [ 3562.121806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
      [ 3562.123075] Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
      [ 3562.124383] Call Trace:
      [ 3562.125640]  dump_stack+0x9a/0xeb
      [ 3562.126911]  print_address_description+0xe3/0x2e0
      [ 3562.128223]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.129545]  __kasan_report+0x15c/0x1df
      [ 3562.130866]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.132174]  kasan_report+0xe/0x20
      [ 3562.133514]  ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.134835]  ? find_mad_agent+0xa00/0xa00 [ib_core]
      [ 3562.136158]  ? qlist_free_all+0x51/0xb0
      [ 3562.137498]  ? mlx4_ib_sqp_comp_worker+0x1970/0x1970 [mlx4_ib]
      [ 3562.138833]  ? quarantine_reduce+0x1fa/0x270
      [ 3562.140171]  ? kasan_unpoison_shadow+0x30/0x40
      [ 3562.141522]  ib_mad_recv_done+0xdf6/0x3000 [ib_core]
      [ 3562.142880]  ? _raw_spin_unlock_irqrestore+0x46/0x70
      [ 3562.144277]  ? ib_mad_send_done+0x1810/0x1810 [ib_core]
      [ 3562.145649]  ? mlx4_ib_destroy_cq+0x2a0/0x2a0 [mlx4_ib]
      [ 3562.147008]  ? _raw_spin_unlock_irqrestore+0x46/0x70
      [ 3562.148380]  ? debug_object_deactivate+0x2b9/0x4a0
      [ 3562.149814]  __ib_process_cq+0xe2/0x1d0 [ib_core]
      [ 3562.151195]  ib_cq_poll_work+0x45/0xf0 [ib_core]
      [ 3562.152577]  process_one_work+0x90c/0x1860
      [ 3562.153959]  ? pwq_dec_nr_in_flight+0x320/0x320
      [ 3562.155320]  worker_thread+0x87/0xbb0
      [ 3562.156687]  ? __kthread_parkme+0xb6/0x180
      [ 3562.158058]  ? process_one_work+0x1860/0x1860
      [ 3562.159429]  kthread+0x320/0x3e0
      [ 3562.161391]  ? kthread_park+0x120/0x120
      [ 3562.162744]  ret_from_fork+0x24/0x30
      ...
      [ 3562.187615] Freed by task 31682:
      [ 3562.188602]  save_stack+0x19/0x80
      [ 3562.189586]  __kasan_slab_free+0x11d/0x160
      [ 3562.190571]  kfree+0xf5/0x2f0
      [ 3562.191552]  ib_mad_port_close+0x200/0x380 [ib_core]
      [ 3562.192538]  ib_mad_remove_device+0xf0/0x230 [ib_core]
      [ 3562.193538]  remove_client_context+0xa6/0xe0 [ib_core]
      [ 3562.194514]  disable_device+0x14e/0x260 [ib_core]
      [ 3562.195488]  __ib_unregister_device+0x79/0x150 [ib_core]
      [ 3562.196462]  ib_unregister_device+0x21/0x30 [ib_core]
      [ 3562.197439]  mlx4_ib_remove+0x162/0x690 [mlx4_ib]
      [ 3562.198408]  mlx4_remove_device+0x204/0x2c0 [mlx4_core]
      [ 3562.199381]  mlx4_unregister_interface+0x49/0x1d0 [mlx4_core]
      [ 3562.200356]  mlx4_ib_cleanup+0xc/0x1d [mlx4_ib]
      [ 3562.201329]  __x64_sys_delete_module+0x2d2/0x400
      [ 3562.202288]  do_syscall_64+0x95/0x470
      [ 3562.203277]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The problem was that the MAD PD was deallocated before the MAD CQ.
      There was completion work pending for the CQ when the PD got deallocated.
      When the mad completion handling reached procedure
      ib_mad_post_receive_mads(), we got a use-after-free bug in the following
      line of code in that procedure:
         sg_list.lkey = qp_info->port_priv->pd->local_dma_lkey;
      (the pd pointer in the above line is no longer valid, because the
      pd has been deallocated).
      
      We fix this by allocating the PD before the CQ in procedure
      ib_mad_port_open(), and deallocating the PD after freeing the CQ
      in procedure ib_mad_port_close().
      
      Since the CQ completion work queue is flushed during ib_free_cq(),
      no completions will be pending for that CQ when the PD is later
      deallocated.
      
      Note that freeing the CQ before deallocating the PD is the practice
      in the ULPs.
      
      Fixes: 4be90bc6 ("IB/mad: Remove ib_get_dma_mr calls")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190801121449.24973-1-leon@kernel.orgSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b4f0fee7
    • Guy Levi's avatar
      IB/mlx5: Fix MR registration flow to use UMR properly · a0258ff4
      Guy Levi authored
      [ Upstream commit e5366d30 ]
      
      Driver shouldn't allow to use UMR to register a MR when
      umr_modify_atomic_disabled is set. Otherwise it will always end up with a
      failure in the post send flow which sets the UMR WQE to modify atomic access
      right.
      
      Fixes: c8d75a98 ("IB/mlx5: Respect new UMR capabilities")
      Signed-off-by: default avatarGuy Levi <guyle@mellanox.com>
      Reviewed-by: default avatarMoni Shoua <monis@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190731081929.32559-1-leon@kernel.orgSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a0258ff4
    • Luck, Tony's avatar
      IB/core: Add mitigation for Spectre V1 · efb742ce
      Luck, Tony authored
      [ Upstream commit 61f25982 ]
      
      Some processors may mispredict an array bounds check and
      speculatively access memory that they should not. With
      a user supplied array index we like to play things safe
      by masking the value with the array size before it is
      used as an index.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Link: https://lore.kernel.org/r/20190731043957.GA1600@agluck-desk2.amr.corp.intel.comSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      efb742ce
    • Qian Cai's avatar
      arm64/mm: fix variable 'pud' set but not used · 4a0d2eee
      Qian Cai authored
      [ Upstream commit 7d4e2dcf ]
      
      GCC throws a warning,
      
      arch/arm64/mm/mmu.c: In function 'pud_free_pmd_page':
      arch/arm64/mm/mmu.c:1033:8: warning: variable 'pud' set but not used
      [-Wunused-but-set-variable]
        pud_t pud;
              ^~~
      
      because pud_table() is a macro and compiled away. Fix it by making it a
      static inline function and for pud_sect() as well.
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4a0d2eee
    • Masami Hiramatsu's avatar
      arm64: unwind: Prohibit probing on return_address() · 6af9263f
      Masami Hiramatsu authored
      [ Upstream commit ee07b93e ]
      
      Prohibit probing on return_address() and subroutines which
      is called from return_address(), since the it is invoked from
      trace_hardirqs_off() which is also kprobe blacklisted.
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6af9263f
    • Qian Cai's avatar
      arm64/efi: fix variable 'si' set but not used · ffb1a76d
      Qian Cai authored
      [ Upstream commit f1d48362 ]
      
      GCC throws out this warning on arm64.
      
      drivers/firmware/efi/libstub/arm-stub.c: In function 'efi_entry':
      drivers/firmware/efi/libstub/arm-stub.c:132:22: warning: variable 'si'
      set but not used [-Wunused-but-set-variable]
      
      Fix it by making free_screen_info() a static inline function.
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ffb1a76d
    • Stephen Boyd's avatar
      kbuild: Check for unknown options with cc-option usage in Kconfig and clang · 48522289
      Stephen Boyd authored
      [ Upstream commit e8de12fb ]
      
      If the particular version of clang a user has doesn't enable
      -Werror=unknown-warning-option by default, even though it is the
      default[1], then make sure to pass the option to the Kconfig cc-option
      command so that testing options from Kconfig files works properly.
      Otherwise, depending on the default values setup in the clang toolchain
      we will silently assume options such as -Wmaybe-uninitialized are
      supported by clang, when they really aren't.
      
      A compilation issue only started happening for me once commit
      589834b3 ("kbuild: Add -Werror=unknown-warning-option to
      CLANG_FLAGS") was applied on top of commit b303c6df ("kbuild:
      compute false-positive -Wmaybe-uninitialized cases in Kconfig"). This
      leads kbuild to try and test for the existence of the
      -Wmaybe-uninitialized flag with the cc-option command in
      scripts/Kconfig.include, and it doesn't see an error returned from the
      option test so it sets the config value to Y. Then the Makefile tries to
      pass the unknown option on the command line and
      -Werror=unknown-warning-option catches the invalid option and breaks the
      build. Before commit 589834b3 ("kbuild: Add
      -Werror=unknown-warning-option to CLANG_FLAGS") the build works fine,
      but any cc-option test of a warning option in Kconfig files silently
      evaluates to true, even if the warning option flag isn't supported on
      clang.
      
      Note: This doesn't change cc-option usages in Makefiles because those
      use a different rule that includes KBUILD_CFLAGS by default (see the
      __cc-option command in scripts/Kbuild.incluide). The KBUILD_CFLAGS
      variable already has the -Werror=unknown-warning-option flag set. Thanks
      to Doug for pointing out the different rule.
      
      [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option
      Cc: Peter Smith <peter.smith@linaro.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Douglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      48522289
    • Masahiro Yamada's avatar
      kbuild: modpost: handle KBUILD_EXTRA_SYMBOLS only for external modules · b3aebdd4
      Masahiro Yamada authored
      [ Upstream commit cb481993 ]
      
      KBUILD_EXTRA_SYMBOLS makes sense only when building external modules.
      Moreover, the modpost sets 'external_module' if the -e option is given.
      
      I replaced $(patsubst %, -e %,...) with simpler $(addprefix -e,...)
      while I was here.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b3aebdd4
    • Miquel Raynal's avatar
      ata: libahci: do not complain in case of deferred probe · 23bc01f0
      Miquel Raynal authored
      [ Upstream commit 090bb803 ]
      
      Retrieving PHYs can defer the probe, do not spawn an error when
      -EPROBE_DEFER is returned, it is normal behavior.
      
      Fixes: b1a9edbd ("ata: libahci: allow to use multiple PHYs")
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      23bc01f0
    • Wang Xiayang's avatar
      drm/amdgpu: fix a potential information leaking bug · 68340db9
      Wang Xiayang authored
      [ Upstream commit 929e571c ]
      
      Coccinelle reports a path that the array "data" is never initialized.
      The path skips the checks in the conditional branches when either
      of callback functions, read_wave_vgprs and read_wave_sgprs, is not
      registered. Later, the uninitialized "data" array is read
      in the while-loop below and passed to put_user().
      
      Fix the path by allocating the array with kcalloc().
      
      The patch is simplier than adding a fall-back branch that explicitly
      calls memset(data, 0, ...). Also it does not need the multiplication
      1024*sizeof(*data) as the size parameter for memset() though there is
      no risk of integer overflow.
      Signed-off-by: default avatarWang Xiayang <xywang.sjtu@sjtu.edu.cn>
      Reviewed-by: default avatarChunming Zhou <david1.zhou@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      68340db9
    • Jia-Ju Bai's avatar
      scsi: qla2xxx: Fix possible fcport null-pointer dereferences · 02d4fe01
      Jia-Ju Bai authored
      [ Upstream commit e82f04ec ]
      
      In qla2x00_alloc_fcport(), fcport is assigned to NULL in the error
      handling code on line 4880:
          fcport = NULL;
      
      Then fcport is used on lines 4883-4886:
          INIT_WORK(&fcport->del_work, qla24xx_delete_sess_fn);
      	INIT_WORK(&fcport->reg_work, qla_register_fcport_fn);
      	INIT_LIST_HEAD(&fcport->gnl_entry);
      	INIT_LIST_HEAD(&fcport->list);
      
      Thus, possible null-pointer dereferences may occur.
      
      To fix these bugs, qla2x00_alloc_fcport() directly returns NULL
      in the error handling code.
      
      These bugs are found by a static analysis tool STCheck written by us.
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      02d4fe01
    • Don Brace's avatar
    • Filipe Manana's avatar
      Btrfs: fix deadlock between fiemap and transaction commits · f833deae
      Filipe Manana authored
      [ Upstream commit a6d155d2 ]
      
      The fiemap handler locks a file range that can have unflushed delalloc,
      and after locking the range, it tries to attach to a running transaction.
      If the running transaction started its commit, that is, it is in state
      TRANS_STATE_COMMIT_START, and either the filesystem was mounted with the
      flushoncommit option or the transaction is creating a snapshot for the
      subvolume that contains the file that fiemap is operating on, we end up
      deadlocking. This happens because fiemap is blocked on the transaction,
      waiting for it to complete, and the transaction is waiting for the flushed
      dealloc to complete, which requires locking the file range that the fiemap
      task already locked. The following stack traces serve as an example of
      when this deadlock happens:
      
        (...)
        [404571.515510] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
        [404571.515956] Call Trace:
        [404571.516360]  ? __schedule+0x3ae/0x7b0
        [404571.516730]  schedule+0x3a/0xb0
        [404571.517104]  lock_extent_bits+0x1ec/0x2a0 [btrfs]
        [404571.517465]  ? remove_wait_queue+0x60/0x60
        [404571.517832]  btrfs_finish_ordered_io+0x292/0x800 [btrfs]
        [404571.518202]  normal_work_helper+0xea/0x530 [btrfs]
        [404571.518566]  process_one_work+0x21e/0x5c0
        [404571.518990]  worker_thread+0x4f/0x3b0
        [404571.519413]  ? process_one_work+0x5c0/0x5c0
        [404571.519829]  kthread+0x103/0x140
        [404571.520191]  ? kthread_create_worker_on_cpu+0x70/0x70
        [404571.520565]  ret_from_fork+0x3a/0x50
        [404571.520915] kworker/u8:6    D    0 31651      2 0x80004000
        [404571.521290] Workqueue: btrfs-flush_delalloc btrfs_flush_delalloc_helper [btrfs]
        (...)
        [404571.537000] fsstress        D    0 13117  13115 0x00004000
        [404571.537263] Call Trace:
        [404571.537524]  ? __schedule+0x3ae/0x7b0
        [404571.537788]  schedule+0x3a/0xb0
        [404571.538066]  wait_current_trans+0xc8/0x100 [btrfs]
        [404571.538349]  ? remove_wait_queue+0x60/0x60
        [404571.538680]  start_transaction+0x33c/0x500 [btrfs]
        [404571.539076]  btrfs_check_shared+0xa3/0x1f0 [btrfs]
        [404571.539513]  ? extent_fiemap+0x2ce/0x650 [btrfs]
        [404571.539866]  extent_fiemap+0x2ce/0x650 [btrfs]
        [404571.540170]  do_vfs_ioctl+0x526/0x6f0
        [404571.540436]  ksys_ioctl+0x70/0x80
        [404571.540734]  __x64_sys_ioctl+0x16/0x20
        [404571.540997]  do_syscall_64+0x60/0x1d0
        [404571.541279]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
        (...)
        [404571.543729] btrfs           D    0 14210  14208 0x00004000
        [404571.544023] Call Trace:
        [404571.544275]  ? __schedule+0x3ae/0x7b0
        [404571.544526]  ? wait_for_completion+0x112/0x1a0
        [404571.544795]  schedule+0x3a/0xb0
        [404571.545064]  schedule_timeout+0x1ff/0x390
        [404571.545351]  ? lock_acquire+0xa6/0x190
        [404571.545638]  ? wait_for_completion+0x49/0x1a0
        [404571.545890]  ? wait_for_completion+0x112/0x1a0
        [404571.546228]  wait_for_completion+0x131/0x1a0
        [404571.546503]  ? wake_up_q+0x70/0x70
        [404571.546775]  btrfs_wait_ordered_extents+0x27c/0x400 [btrfs]
        [404571.547159]  btrfs_commit_transaction+0x3b0/0xae0 [btrfs]
        [404571.547449]  ? btrfs_mksubvol+0x4a4/0x640 [btrfs]
        [404571.547703]  ? remove_wait_queue+0x60/0x60
        [404571.547969]  btrfs_mksubvol+0x605/0x640 [btrfs]
        [404571.548226]  ? __sb_start_write+0xd4/0x1c0
        [404571.548512]  ? mnt_want_write_file+0x24/0x50
        [404571.548789]  btrfs_ioctl_snap_create_transid+0x169/0x1a0 [btrfs]
        [404571.549048]  btrfs_ioctl_snap_create_v2+0x11d/0x170 [btrfs]
        [404571.549307]  btrfs_ioctl+0x133f/0x3150 [btrfs]
        [404571.549549]  ? mem_cgroup_charge_statistics+0x4c/0xd0
        [404571.549792]  ? mem_cgroup_commit_charge+0x84/0x4b0
        [404571.550064]  ? __handle_mm_fault+0xe3e/0x11f0
        [404571.550306]  ? do_raw_spin_unlock+0x49/0xc0
        [404571.550608]  ? _raw_spin_unlock+0x24/0x30
        [404571.550976]  ? __handle_mm_fault+0xedf/0x11f0
        [404571.551319]  ? do_vfs_ioctl+0xa2/0x6f0
        [404571.551659]  ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
        [404571.552087]  do_vfs_ioctl+0xa2/0x6f0
        [404571.552355]  ksys_ioctl+0x70/0x80
        [404571.552621]  __x64_sys_ioctl+0x16/0x20
        [404571.552864]  do_syscall_64+0x60/0x1d0
        [404571.553104]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
        (...)
      
      If we were joining the transaction instead of attaching to it, we would
      not risk a deadlock because a join only blocks if the transaction is in a
      state greater then or equals to TRANS_STATE_COMMIT_DOING, and the delalloc
      flush performed by a transaction is done before it reaches that state,
      when it is in the state TRANS_STATE_COMMIT_START. However a transaction
      join is intended for use cases where we do modify the filesystem, and
      fiemap only needs to peek at delayed references from the current
      transaction in order to determine if extents are shared, and, besides
      that, when there is no current transaction or when it blocks to wait for
      a current committing transaction to complete, it creates a new transaction
      without reserving any space. Such unnecessary transactions, besides doing
      unnecessary IO, can cause transaction aborts (-ENOSPC) and unnecessary
      rotation of the precious backup roots.
      
      So fix this by adding a new transaction join variant, named join_nostart,
      which behaves like the regular join, but it does not create a transaction
      when none currently exists or after waiting for a committing transaction
      to complete.
      
      Fixes: 03628cdb ("Btrfs: do not start a transaction during fiemap")
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f833deae
    • YueHaibing's avatar
      drm/bridge: lvds-encoder: Fix build error while CONFIG_DRM_KMS_HELPER=m · 202aa96f
      YueHaibing authored
      [ Upstream commit f4cc743a ]
      
      If DRM_LVDS_ENCODER=y but CONFIG_DRM_KMS_HELPER=m,
      build fails:
      
      drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
      lvds-encoder.c:(.text+0x155): undefined reference to `devm_drm_panel_bridge_add'
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: dbb58bfd ("drm/bridge: Fix lvds-encoder since the panel_bridge rework.")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190729071216.27488-1-yuehaibing@huawei.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      202aa96f
    • Kees Cook's avatar
      libata: zpodd: Fix small read overflow in zpodd_get_mech_type() · f69fd790
      Kees Cook authored
      [ Upstream commit 71d6c505 ]
      
      Jeffrin reported a KASAN issue:
      
        BUG: KASAN: global-out-of-bounds in ata_exec_internal_sg+0x50f/0xc70
        Read of size 16 at addr ffffffff91f41f80 by task scsi_eh_1/149
        ...
        The buggy address belongs to the variable:
          cdb.48319+0x0/0x40
      
      Much like commit 18c9a99b ("libata: zpodd: small read overflow in
      eject_tray()"), this fixes a cdb[] buffer length, this time in
      zpodd_get_mech_type():
      
      We read from the cdb[] buffer in ata_exec_internal_sg(). It has to be
      ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes.
      Reported-by: default avatarJeffrin Jose T <jeffrin@rajagiritech.edu.in>
      Fixes: afe75951 ("libata: identify and init ZPODD devices")
      Link: https://lore.kernel.org/lkml/201907181423.E808958@keescook/Tested-by: default avatarJeffrin Jose T <jeffrin@rajagiritech.edu.in>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f69fd790
    • Numfor Mbiziwo-Tiapo's avatar
      perf header: Fix use of unitialized value warning · 0a19fff5
      Numfor Mbiziwo-Tiapo authored
      [ Upstream commit 20f9781f ]
      
      When building our local version of perf with MSAN (Memory Sanitizer) and
      running the perf record command, MSAN throws a use of uninitialized
      value warning in "tools/perf/util/util.c:333:6".
      
      This warning stems from the "buf" variable being passed into "write".
      It originated as the variable "ev" with the type union perf_event*
      defined in the "perf_event__synthesize_attr" function in
      "tools/perf/util/header.c".
      
      In the "perf_event__synthesize_attr" function they allocate space with a malloc
      call using ev, then go on to only assign some of the member variables before
      passing "ev" on as a parameter to the "process" function therefore "ev"
      contains uninitialized memory. Changing the malloc call to zalloc to initialize
      all the members of "ev" which gets rid of the warning.
      
      To reproduce this warning, build perf by running:
      make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-fsanitize=memory\
       -fsanitize-memory-track-origins"
      
      (Additionally, llvm might have to be installed and clang might have to
      be specified as the compiler - export CC=/usr/bin/clang)
      
      then running:
      tools/perf/perf record -o - ls / | tools/perf/perf --no-pager annotate\
       -i - --stdio
      
      Please see the cover letter for why false positive warnings may be
      generated.
      Signed-off-by: default avatarNumfor Mbiziwo-Tiapo <nums@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Drayton <mbd@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20190724234500.253358-2-nums@google.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0a19fff5
    • Vince Weaver's avatar
      perf header: Fix divide by zero error if f_header.attr_size==0 · ab5aa579
      Vince Weaver authored
      [ Upstream commit 7622236c ]
      
      So I have been having lots of trouble with hand-crafted perf.data files
      causing segfaults and the like, so I have started fuzzing the perf tool.
      
      First issue found:
      
      If f_header.attr_size is 0 in the perf.data file, then perf will crash
      with a divide-by-zero error.
      
      Committer note:
      
      Added a pr_err() to tell the user why the command failed.
      Signed-off-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1907231100440.14532@macbook-airSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ab5aa579
    • Lucas Stach's avatar
      irqchip/irq-imx-gpcv2: Forward irq type to parent · a5e40452
      Lucas Stach authored
      [ Upstream commit 9a446ef0 ]
      
      The GPCv2 is a stacked IRQ controller below the ARM GIC. It doesn't
      care about the IRQ type itself, but needs to forward the type to the
      parent IRQ controller, so this one can be configured correctly.
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a5e40452
    • Nianyao Tang's avatar
      irqchip/gic-v3-its: Free unused vpt_page when alloc vpe table fail · dcb73180
      Nianyao Tang authored
      [ Upstream commit 34f8eb92 ]
      
      In its_vpe_init, when its_alloc_vpe_table fails, we should free
      vpt_page allocated just before, instead of vpe->vpt_page.
      Let's fix it.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarNianyao Tang <tangnianyao@huawei.com>
      Signed-off-by: default avatarShaokun Zhang <zhangshaokun@hisilicon.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dcb73180
    • YueHaibing's avatar
      xen/pciback: remove set but not used variable 'old_state' · e72e6ba1
      YueHaibing authored
      [ Upstream commit 09e088a4 ]
      
      Fixes gcc '-Wunused-but-set-variable' warning:
      
      drivers/xen/xen-pciback/conf_space_capability.c: In function pm_ctrl_write:
      drivers/xen/xen-pciback/conf_space_capability.c:119:25: warning:
       variable old_state set but not used [-Wunused-but-set-variable]
      
      It is never used so can be removed.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e72e6ba1
    • Geert Uytterhoeven's avatar
      clk: renesas: cpg-mssr: Fix reset control race condition · ca5b26a8
      Geert Uytterhoeven authored
      [ Upstream commit e1f1ae80 ]
      
      The module reset code in the Renesas CPG/MSSR driver uses
      read-modify-write (RMW) operations to write to a Software Reset Register
      (SRCRn), and simple writes to write to a Software Reset Clearing
      Register (SRSTCLRn), as was mandated by the R-Car Gen2 and Gen3 Hardware
      User's Manuals.
      
      However, this may cause a race condition when two devices are reset in
      parallel: if the reset for device A completes in the middle of the RMW
      operation for device B, device A may be reset again, causing subtle
      failures (e.g. i2c timeouts):
      
      	thread A			thread B
      	--------			--------
      
      	val = SRCRn
      	val |= bit A
      	SRCRn = val
      
      	delay
      
      					val = SRCRn (bit A is set)
      
      	SRSTCLRn = bit A
      	(bit A in SRCRn is cleared)
      
      					val |= bit B
      					SRCRn = val (bit A and B are set)
      
      This can be reproduced on e.g. Salvator-XS using:
      
          $ while true; do i2cdump -f -y 4 0x6A b > /dev/null; done &
          $ while true; do i2cdump -f -y 2 0x10 b > /dev/null; done &
      
          i2c-rcar e6510000.i2c: error -110 : 40000002
          i2c-rcar e66d8000.i2c: error -110 : 40000002
      
      According to the R-Car Gen3 Hardware Manual Errata for Rev.
      0.80 of Feb 28, 2018, reflected in Rev. 1.00 of the R-Car Gen3 Hardware
      User's Manual, writes to SRCRn do not require read-modify-write cycles.
      
      Note that the R-Car Gen2 Hardware User's Manual has not been updated
      yet, and still says a read-modify-write sequence is required.  According
      to the hardware team, the reset hardware block is the same on both R-Car
      Gen2 and Gen3, though.
      
      Hence fix the issue by replacing the read-modify-write operations on
      SRCRn by simple writes.
      Reported-by: default avatarYao Lihua <Lihua.Yao@desay-svautomotive.com>
      Fixes: 6197aa65 ("clk: renesas: cpg-mssr: Add support for reset control")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: default avatarLinh Phung <linh.phung.jy@renesas.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ca5b26a8
    • Chunyan Zhang's avatar
      clk: sprd: Select REGMAP_MMIO to avoid compile errors · af2ed1a0
      Chunyan Zhang authored
      [ Upstream commit c9a67cbb ]
      
      Make REGMAP_MMIO selected to avoid undefined reference to regmap symbols.
      
      Fixes: d41f59fd ("clk: sprd: Add common infrastructure")
      Signed-off-by: default avatarChunyan Zhang <chunyan.zhang@unisoc.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      af2ed1a0
    • Codrin Ciubotariu's avatar
      clk: at91: generated: Truncate divisor to GENERATED_MAX_DIV + 1 · 3e5f29b6
      Codrin Ciubotariu authored
      [ Upstream commit 1573eebe ]
      
      In clk_generated_determine_rate(), if the divisor is greater than
      GENERATED_MAX_DIV + 1, then the wrong best_rate will be returned.
      If clk_generated_set_rate() will be called later with this wrong
      rate, it will return -EINVAL, so the generated clock won't change
      its value. Do no let the divisor be greater than GENERATED_MAX_DIV + 1.
      
      Fixes: 8c7aa632 ("clk: at91: clk-generated: remove useless divisor loop")
      Signed-off-by: default avatarCodrin Ciubotariu <codrin.ciubotariu@microchip.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3e5f29b6
    • Vincent Chen's avatar
      riscv: Make __fstate_clean() work correctly. · 28fd9b37
      Vincent Chen authored
      commit 69703eb9 upstream.
      
      Make the __fstate_clean() function correctly set the
      state of sstatus.FS in pt_regs to SR_FS_CLEAN.
      
      Fixes: 7db91e57 ("RISC-V: Task implementation")
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarVincent Chen <vincent.chen@sifive.com>
      Reviewed-by: default avatarAnup Patel <anup@brainfault.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      [paul.walmsley@sifive.com: expanded "Fixes" commit ID]
      Signed-off-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28fd9b37
    • Florian Westphal's avatar
      netfilter: ebtables: also count base chain policies · cef0e9eb
      Florian Westphal authored
      commit 3b48300d upstream.
      
      ebtables doesn't include the base chain policies in the rule count,
      so we need to add them manually when we call into the x_tables core
      to allocate space for the comapt offset table.
      
      This lead syzbot to trigger:
      WARNING: CPU: 1 PID: 9012 at net/netfilter/x_tables.c:649
      xt_compat_add_offset.cold+0x11/0x36 net/netfilter/x_tables.c:649
      
      Reported-by: syzbot+276ddebab3382bbf72db@syzkaller.appspotmail.com
      Fixes: 2035f3ff ("netfilter: ebtables: compat: un-break 32bit setsockopt when no rules are present")
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cef0e9eb
    • Denis Kirjanov's avatar
      net: usb: pegasus: fix improper read if get_registers() fail · 07d92cae
      Denis Kirjanov authored
      commit 224c0497 upstream.
      
      get_registers() may fail with -ENOMEM and in this
      case we can read a garbage from the status variable tmp.
      
      Reported-by: syzbot+3499a83b2d062ae409d4@syzkaller.appspotmail.com
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07d92cae
    • Oliver Neukum's avatar
      Input: iforce - add sanity checks · f13de3d6
      Oliver Neukum authored
      commit 849f5ae3 upstream.
      
      The endpoint type should also be checked before a device
      is accepted.
      
      Reported-by: syzbot+5efc10c005014d061a74@syzkaller.appspotmail.com
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f13de3d6
    • Oliver Neukum's avatar
      Input: kbtab - sanity check for endpoint type · 08b3af00
      Oliver Neukum authored
      commit c88090df upstream.
      
      The driver should check whether the endpoint it uses has the correct
      type.
      
      Reported-by: syzbot+c7df50363aaff50aa363@syzkaller.appspotmail.com
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08b3af00
    • Hillf Danton's avatar
      HID: hiddev: do cleanup in failure of opening a device · b545dc9d
      Hillf Danton authored
      commit 6d4472d7 upstream.
      
      Undo what we did for opening before releasing the memory slice.
      Reported-by: default avatarsyzbot <syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarHillf Danton <hdanton@sina.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b545dc9d
    • Hillf Danton's avatar
      HID: hiddev: avoid opening a disconnected device · 0aab1a46
      Hillf Danton authored
      commit 9c09b214 upstream.
      
      syzbot found the following crash on:
      
      HEAD commit:    e96407b4 usb-fuzzer: main usb gadget fuzzer driver
      git tree:       https://github.com/google/kasan.git usb-fuzzer
      console output: https://syzkaller.appspot.com/x/log.txt?x=147ac20c600000
      kernel config:  https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
      dashboard link: https://syzkaller.appspot.com/bug?extid=62a1e04fd3ec2abf099e
      compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
      
      ==================================================================
      BUG: KASAN: use-after-free in __lock_acquire+0x302a/0x3b50
      kernel/locking/lockdep.c:3753
      Read of size 8 at addr ffff8881cf591a08 by task syz-executor.1/26260
      
      CPU: 1 PID: 26260 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #24
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0xca/0x13e lib/dump_stack.c:113
        print_address_description+0x6a/0x32c mm/kasan/report.c:351
        __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
        kasan_report+0xe/0x12 mm/kasan/common.c:612
        __lock_acquire+0x302a/0x3b50 kernel/locking/lockdep.c:3753
        lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
        __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
        _raw_spin_lock_irqsave+0x32/0x50 kernel/locking/spinlock.c:159
        hiddev_release+0x82/0x520 drivers/hid/usbhid/hiddev.c:221
        __fput+0x2d7/0x840 fs/file_table.c:280
        task_work_run+0x13f/0x1c0 kernel/task_work.c:113
        exit_task_work include/linux/task_work.h:22 [inline]
        do_exit+0x8ef/0x2c50 kernel/exit.c:878
        do_group_exit+0x125/0x340 kernel/exit.c:982
        get_signal+0x466/0x23d0 kernel/signal.c:2728
        do_signal+0x88/0x14e0 arch/x86/kernel/signal.c:815
        exit_to_usermode_loop+0x1a2/0x200 arch/x86/entry/common.c:159
        prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
        syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
        do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x459829
      Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f75b2a6ccf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
      RAX: fffffffffffffe00 RBX: 000000000075c078 RCX: 0000000000459829
      RDX: 0000000000000000 RSI: 0000000000000080 RDI: 000000000075c078
      RBP: 000000000075c070 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 000000000075c07c
      R13: 00007ffcdfe1023f R14: 00007f75b2a6d9c0 R15: 000000000075c07c
      
      Allocated by task 104:
        save_stack+0x1b/0x80 mm/kasan/common.c:69
        set_track mm/kasan/common.c:77 [inline]
        __kasan_kmalloc mm/kasan/common.c:487 [inline]
        __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
        kmalloc include/linux/slab.h:552 [inline]
        kzalloc include/linux/slab.h:748 [inline]
        hiddev_connect+0x242/0x5b0 drivers/hid/usbhid/hiddev.c:900
        hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
        hid_hw_start drivers/hid/hid-core.c:1981 [inline]
        hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
        appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
        hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
        usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
        usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
        generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
        usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
        hub_port_connect drivers/usb/core/hub.c:5098 [inline]
        hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
        port_event drivers/usb/core/hub.c:5359 [inline]
        hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
        process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
        worker_thread+0x96/0xe20 kernel/workqueue.c:2415
        kthread+0x318/0x420 kernel/kthread.c:255
        ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      Freed by task 104:
        save_stack+0x1b/0x80 mm/kasan/common.c:69
        set_track mm/kasan/common.c:77 [inline]
        __kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
        slab_free_hook mm/slub.c:1423 [inline]
        slab_free_freelist_hook mm/slub.c:1470 [inline]
        slab_free mm/slub.c:3012 [inline]
        kfree+0xe4/0x2f0 mm/slub.c:3953
        hiddev_connect.cold+0x45/0x5c drivers/hid/usbhid/hiddev.c:914
        hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
        hid_hw_start drivers/hid/hid-core.c:1981 [inline]
        hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
        appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
        hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
        usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
        usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
        generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
        usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
        hub_port_connect drivers/usb/core/hub.c:5098 [inline]
        hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
        port_event drivers/usb/core/hub.c:5359 [inline]
        hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
        process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
        worker_thread+0x96/0xe20 kernel/workqueue.c:2415
        kthread+0x318/0x420 kernel/kthread.c:255
        ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      The buggy address belongs to the object at ffff8881cf591900
        which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 264 bytes inside of
        512-byte region [ffff8881cf591900, ffff8881cf591b00)
      The buggy address belongs to the page:
      page:ffffea00073d6400 refcount:1 mapcount:0 mapping:ffff8881da002500
      index:0x0 compound_mapcount: 0
      flags: 0x200000000010200(slab|head)
      raw: 0200000000010200 0000000000000000 0000000100000001 ffff8881da002500
      raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
        ffff8881cf591900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff8881cf591980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      > ffff8881cf591a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                             ^
        ffff8881cf591a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff8881cf591b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      
      In order to avoid opening a disconnected device, we need to check exist
      again after acquiring the existance lock, and bail out if necessary.
      Reported-by: default avatarsyzbot <syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarHillf Danton <hdanton@sina.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0aab1a46
    • Oliver Neukum's avatar
      HID: holtek: test for sanity of intfdata · 537d957b
      Oliver Neukum authored
      commit 01ec0a5f upstream.
      
      The ioctl handler uses the intfdata of a second interface,
      which may not be present in a broken or malicious device, hence
      the intfdata needs to be checked for NULL.
      
      [jkosina@suse.cz: fix newly added spurious space]
      Reported-by: syzbot+965152643a75a56737be@syzkaller.appspotmail.com
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      537d957b
    • Hui Wang's avatar
      ALSA: hda - Let all conexant codec enter D3 when rebooting · 9585f444
      Hui Wang authored
      commit 401714d9 upstream.
      
      We have 3 new lenovo laptops which have conexant codec 0x14f11f86,
      these 3 laptops also have the noise issue when rebooting, after
      letting the codec enter D3 before rebooting or poweroff, the noise
      disappers.
      
      Instead of adding a new ID again in the reboot_notify(), let us make
      this function apply to all conexant codec. In theory make codec enter
      D3 before rebooting or poweroff is harmless, and I tested this change
      on a couple of other Lenovo laptops which have different conexant
      codecs, there is no side effect so far.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9585f444
    • Hui Wang's avatar
      ALSA: hda - Add a generic reboot_notify · e58ba88d
      Hui Wang authored
      commit 871b9066 upstream.
      
      Make codec enter D3 before rebooting or poweroff can fix the noise
      issue on some laptops. And in theory it is harmless for all codecs
      to enter D3 before rebooting or poweroff, let us add a generic
      reboot_notify, then realtek and conexant drivers can call this
      function.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e58ba88d
    • Wenwen Wang's avatar
      ALSA: hda - Fix a memory leak bug · 6c4a536c
      Wenwen Wang authored
      commit cfef67f0 upstream.
      
      In snd_hda_parse_generic_codec(), 'spec' is allocated through kzalloc().
      Then, the pin widgets in 'codec' are parsed. However, if the parsing
      process fails, 'spec' is not deallocated, leading to a memory leak.
      
      To fix the above issue, free 'spec' before returning the error.
      
      Fixes: 352f7f91 ("ALSA: hda - Merge Realtek parser code to generic parser")
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c4a536c