1. 22 Jun, 2019 40 commits
    • Andrea Arcangeli's avatar
      coredump: fix race condition between collapse_huge_page() and core dumping · dc30d2ce
      Andrea Arcangeli authored
      commit 59ea6d06cfa9247b586a695c21f94afa7183af74 upstream.
      
      When fixing the race conditions between the coredump and the mmap_sem
      holders outside the context of the process, we focused on
      mmget_not_zero()/get_task_mm() callers in 04f5866e41fb70 ("coredump: fix
      race condition between mmget_not_zero()/get_task_mm() and core
      dumping"), but those aren't the only cases where the mmap_sem can be
      taken outside of the context of the process as Michal Hocko noticed
      while backporting that commit to older -stable kernels.
      
      If mmgrab() is called in the context of the process, but then the
      mm_count reference is transferred outside the context of the process,
      that can also be a problem if the mmap_sem has to be taken for writing
      through that mm_count reference.
      
      khugepaged registration calls mmgrab() in the context of the process,
      but the mmap_sem for writing is taken later in the context of the
      khugepaged kernel thread.
      
      collapse_huge_page() after taking the mmap_sem for writing doesn't
      modify any vma, so it's not obvious that it could cause a problem to the
      coredump, but it happens to modify the pmd in a way that breaks an
      invariant that pmd_trans_huge_lock() relies upon.  collapse_huge_page()
      needs the mmap_sem for writing just to block concurrent page faults that
      call pmd_trans_huge_lock().
      
      Specifically the invariant that "!pmd_trans_huge()" cannot become a
      "pmd_trans_huge()" doesn't hold while collapse_huge_page() runs.
      
      The coredump will call __get_user_pages() without mmap_sem for reading,
      which eventually can invoke a lockless page fault which will need a
      functional pmd_trans_huge_lock().
      
      So collapse_huge_page() needs to use mmget_still_valid() to check it's
      not running concurrently with the coredump...  as long as the coredump
      can invoke page faults without holding the mmap_sem for reading.
      
      This has "Fixes: khugepaged" to facilitate backporting, but in my view
      it's more a bug in the coredump code that will eventually have to be
      rewritten to stop invoking page faults without the mmap_sem for reading.
      So the long term plan is still to drop all mmget_still_valid().
      
      Link: http://lkml.kernel.org/r/20190607161558.32104-1-aarcange@redhat.com
      Fixes: ba76149f ("thp: khugepaged")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: Jason Gunthorpe <jgg@mellanox.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc30d2ce
    • Jason Gerecke's avatar
      HID: wacom: Send BTN_TOUCH in response to INTUOSP2_BT eraser contact · 7212a4c4
      Jason Gerecke authored
      commit fe7f8d73d1af19b678171170e4e5384deb57833d upstream.
      
      The Bluetooth reports from the 2nd-gen Intuos Pro have separate bits for
      indicating if the tip or eraser is in contact with the tablet. At the
      moment, only the tip contact bit controls the state of the BTN_TOUCH
      event. This prevents the eraser from working as expected. This commit
      changes the driver to send BTN_TOUCH whenever either the tip or eraser
      contact bit is set.
      
      Fixes: 4922cd26 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
      Cc: <stable@vger.kernel.org> # 4.11+
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarAaron Skomra <aaron.skomra@wacom.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7212a4c4
    • Jason Gerecke's avatar
      HID: wacom: Don't report anything prior to the tool entering range · 6fff9ed6
      Jason Gerecke authored
      commit e92a7be7fe5b2510fa60965eaf25f9e3dc08b8cc upstream.
      
      If the tool spends some time in prox before entering range, a series of
      events (e.g. ABS_DISTANCE, MSC_SERIAL) can be sent before we or userspace
      have any clue about the pen whose data is being reported. We need to hold
      off on reporting anything until the pen has entered range. Since we still
      want to report events that occur "in prox" after the pen has *left* range
      we use 'wacom-tool[0]' as the indicator that the pen did at one point
      enter range and provide us/userspace with tool type and serial number
      information.
      
      Fixes: a48324de ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
      Cc: <stable@vger.kernel.org> # 4.11+
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarAaron Armstrong Skomra <aaron.skomra@wacom.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6fff9ed6
    • Jason Gerecke's avatar
      HID: wacom: Don't set tool type until we're in range · bed5114a
      Jason Gerecke authored
      commit 2cc08800a6b9fcda7c7afbcf2da1a6e8808da725 upstream.
      
      The serial number and tool type information that is reported by the tablet
      while a pen is merely "in prox" instead of fully "in range" can be stale
      and cause us to report incorrect tool information. Serial number, tool
      type, and other information is only valid once the pen comes fully in range
      so we should be careful to not use this information until that point.
      
      In particular, this issue may cause the driver to incorectly report
      BTN_TOOL_RUBBER after switching from the eraser tool back to the pen.
      
      Fixes: a48324de ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
      Cc: <stable@vger.kernel.org> # 4.11+
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarAaron Armstrong Skomra <aaron.skomra@wacom.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bed5114a
    • Amit Cohen's avatar
      mlxsw: spectrum: Prevent force of 56G · 3b7bb93e
      Amit Cohen authored
      [ Upstream commit 275e928f19117d22f6d26dee94548baf4041b773 ]
      
      Force of 56G is not supported by hardware in Ethernet devices. This
      configuration fails with a bad parameter error from firmware.
      
      Add check of this case. Instead of trying to set 56G with autoneg off,
      return a meaningful error.
      
      Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
      Signed-off-by: default avatarAmit Cohen <amitc@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3b7bb93e
    • Jason Yan's avatar
      scsi: libsas: delete sas port if expander discover failed · 5992a692
      Jason Yan authored
      [ Upstream commit 3b0541791453fbe7f42867e310e0c9eb6295364d ]
      
      The sas_port(phy->port) allocated in sas_ex_discover_expander() will not be
      deleted when the expander failed to discover. This will cause resource leak
      and a further issue of kernel BUG like below:
      
      [159785.843156]  port-2:17:29: trying to add phy phy-2:17:29 fails: it's
      already part of another port
      [159785.852144] ------------[ cut here  ]------------
      [159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086!
      [159785.863000] Internal error: Oops - BUG: 0 [#1] SMP
      [159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G
      W  OE     4.19.25-vhulk1901.1.0.h111.aarch64 #1
      [159785.878458] Hardware name: Huawei Technologies Co., Ltd.
      Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019
      [159785.889231] Workqueue: 0000:74:02.0_disco_q sas_discover_domain
      [159785.895224] pstate: 40c00009 (nZcv daif +PAN +UAO)
      [159785.900094] pc : sas_port_add_phy+0x188/0x1b8
      [159785.904524] lr : sas_port_add_phy+0x188/0x1b8
      [159785.908952] sp : ffff0001120e3b80
      [159785.912341] x29: ffff0001120e3b80 x28: 0000000000000000
      [159785.917727] x27: ffff802ade8f5400 x26: ffff0000681b7560
      [159785.923111] x25: ffff802adf11a800 x24: ffff0000680e8000
      [159785.928496] x23: ffff802ade8f5728 x22: ffff802ade8f5708
      [159785.933880] x21: ffff802adea2db40 x20: ffff802ade8f5400
      [159785.939264] x19: ffff802adea2d800 x18: 0000000000000010
      [159785.944649] x17: 00000000821bf734 x16: ffff00006714faa0
      [159785.950033] x15: ffff0000e8ab4ecf x14: 7261702079646165
      [159785.955417] x13: 726c612073277469 x12: ffff00006887b830
      [159785.960802] x11: ffff00006773eaa0 x10: 7968702079687020
      [159785.966186] x9 : 0000000000002453 x8 : 726f702072656874
      [159785.971570] x7 : 6f6e6120666f2074 x6 : ffff802bcfb21290
      [159785.976955] x5 : ffff802bcfb21290 x4 : 0000000000000000
      [159785.982339] x3 : ffff802bcfb298c8 x2 : 337752b234c2ab00
      [159785.987723] x1 : 337752b234c2ab00 x0 : 0000000000000000
      [159785.993108] Process kworker/u96:2 (pid: 16993, stack limit =
      0x0000000072dae094)
      [159786.000576] Call trace:
      [159786.003097]  sas_port_add_phy+0x188/0x1b8
      [159786.007179]  sas_ex_get_linkrate.isra.5+0x134/0x140
      [159786.012130]  sas_ex_discover_expander+0x128/0x408
      [159786.016906]  sas_ex_discover_dev+0x218/0x4c8
      [159786.021249]  sas_ex_discover_devices+0x9c/0x1a8
      [159786.025852]  sas_discover_root_expander+0x134/0x160
      [159786.030802]  sas_discover_domain+0x1b8/0x1e8
      [159786.035148]  process_one_work+0x1b4/0x3f8
      [159786.039230]  worker_thread+0x54/0x470
      [159786.042967]  kthread+0x134/0x138
      [159786.046269]  ret_from_fork+0x10/0x18
      [159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d4210000)
      [159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE)
      hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE)
      [159786.067202] ---[ end trace 03622b9e2d99e196  ]---
      [159786.071893] Kernel panic - not syncing: Fatal exception
      [159786.077190] SMP: stopping secondary CPUs
      [159786.081192] Kernel Offset: disabled
      [159786.084753] CPU features: 0x2,a2a00a38
      
      Fixes: 2908d778 ("[SCSI] aic94xx: new driver")
      Reported-by: default avatarJian Luo <luojian5@huawei.com>
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      CC: John Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5992a692
    • YueHaibing's avatar
      scsi: scsi_dh_alua: Fix possible null-ptr-deref · b7f53af5
      YueHaibing authored
      [ Upstream commit 12e750bc62044de096ab9a95201213fd912b9994 ]
      
      If alloc_workqueue fails in alua_init, it should return -ENOMEM, otherwise
      it will trigger null-ptr-deref while unloading module which calls
      destroy_workqueue dereference
      wq->lock like this:
      
      BUG: KASAN: null-ptr-deref in __lock_acquire+0x6b4/0x1ee0
      Read of size 8 at addr 0000000000000080 by task syz-executor.0/7045
      
      CPU: 0 PID: 7045 Comm: syz-executor.0 Tainted: G         C        5.1.0+ #28
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
      Call Trace:
       dump_stack+0xa9/0x10e
       __kasan_report+0x171/0x18d
       ? __lock_acquire+0x6b4/0x1ee0
       kasan_report+0xe/0x20
       __lock_acquire+0x6b4/0x1ee0
       lock_acquire+0xb4/0x1b0
       __mutex_lock+0xd8/0xb90
       drain_workqueue+0x25/0x290
       destroy_workqueue+0x1f/0x3f0
       __x64_sys_delete_module+0x244/0x330
       do_syscall_64+0x72/0x2a0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 03197b61 ("scsi_dh_alua: Use workqueue for RTPG")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b7f53af5
    • Lianbo Jiang's avatar
      scsi: smartpqi: properly set both the DMA mask and the coherent DMA mask · 558ca95d
      Lianbo Jiang authored
      [ Upstream commit 1d94f06e7f5df4064ef336b7b710f50143b64a53 ]
      
      When SME is enabled, the smartpqi driver won't work on the HP DL385 G10
      machine, which causes the failure of kernel boot because it fails to
      allocate pqi error buffer. Please refer to the kernel log:
      ....
      [    9.431749] usbcore: registered new interface driver uas
      [    9.441524] Microsemi PQI Driver (v1.1.4-130)
      [    9.442956] i40e 0000:04:00.0: fw 6.70.48768 api 1.7 nvm 10.2.5
      [    9.447237] smartpqi 0000:23:00.0: Microsemi Smart Family Controller found
               Starting dracut initqueue hook...
      [  OK  ] Started Show Plymouth Boot Scre[    9.471654] Broadcom NetXtreme-C/E driver bnxt_en v1.9.1
      en.
      [  OK  ] Started Forward Password Requests to Plymouth Directory Watch.
      [[0;[    9.487108] smartpqi 0000:23:00.0: failed to allocate PQI error buffer
      ....
      [  139.050544] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts
      [  139.589779] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts
      
      Basically, the fact that the coherent DMA mask value wasn't set caused the
      driver to fall back to SWIOTLB when SME is active.
      
      For correct operation, lets call the dma_set_mask_and_coherent() to
      properly set the mask for both streaming and coherent, in order to inform
      the kernel about the devices DMA addressing capabilities.
      Signed-off-by: default avatarLianbo Jiang <lijiang@redhat.com>
      Acked-by: default avatarDon Brace <don.brace@microsemi.com>
      Tested-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      558ca95d
    • Varun Prakash's avatar
      scsi: libcxgbi: add a check for NULL pointer in cxgbi_check_route() · 60ac7a48
      Varun Prakash authored
      [ Upstream commit cc555759117e8349088e0c5d19f2f2a500bafdbd ]
      
      ip_dev_find() can return NULL so add a check for NULL pointer.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      60ac7a48
    • Max Uvarov's avatar
      net: phy: dp83867: Set up RGMII TX delay · 90abd7a3
      Max Uvarov authored
      [ Upstream commit 2b892649254fec01678c64f16427622b41fa27f4 ]
      
      PHY_INTERFACE_MODE_RGMII_RXID is less then TXID
      so code to set tx delay is never called.
      
      Fixes: 2a10154a ("net: phy: dp83867: Add TI dp83867 phy")
      Signed-off-by: default avatarMax Uvarov <muvarov@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      90abd7a3
    • Yoshihiro Shimoda's avatar
      net: sh_eth: fix mdio access in sh_eth_close() for R-Car Gen2 and RZ/A1 SoCs · da39ca31
      Yoshihiro Shimoda authored
      [ Upstream commit 315ca92dd863fecbffc0bb52ae0ac11e0398726a ]
      
      The sh_eth_close() resets the MAC and then calls phy_stop()
      so that mdio read access result is incorrect without any error
      according to kernel trace like below:
      
      ifconfig-216   [003] .n..   109.133124: mdio_access: ee700000.ethernet-ffffffff read  phy:0x01 reg:0x00 val:0xffff
      
      According to the hardware manual, the RMII mode should be set to 1
      before operation the Ethernet MAC. However, the previous code was not
      set to 1 after the driver issued the soft_reset in sh_eth_dev_exit()
      so that the mdio read access result seemed incorrect. To fix the issue,
      this patch adds a condition and set the RMII mode register in
      sh_eth_dev_exit() for R-Car Gen2 and RZ/A1 SoCs.
      
      Note that when I have tried to move the sh_eth_dev_exit() calling
      after phy_stop() on sh_eth_close(), but it gets worse (kernel panic
      happened and it seems that a register is accessed while the clock is
      off).
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      da39ca31
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Don't take kvm->lock around kvm_for_each_vcpu · 5390e7fa
      Paul Mackerras authored
      [ Upstream commit 5a3f49364c3ffa1107bd88f8292406e98c5d206c ]
      
      Currently the HV KVM code takes the kvm->lock around calls to
      kvm_for_each_vcpu() and kvm_get_vcpu_by_id() (which can call
      kvm_for_each_vcpu() internally).  However, that leads to a lock
      order inversion problem, because these are called in contexts where
      the vcpu mutex is held, but the vcpu mutexes nest within kvm->lock
      according to Documentation/virtual/kvm/locking.txt.  Hence there
      is a possibility of deadlock.
      
      To fix this, we simply don't take the kvm->lock mutex around these
      calls.  This is safe because the implementations of kvm_for_each_vcpu()
      and kvm_get_vcpu_by_id() have been designed to be able to be called
      locklessly.
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: default avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5390e7fa
    • Paul Mackerras's avatar
      KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token list · 308a245a
      Paul Mackerras authored
      [ Upstream commit 1659e27d2bc1ef47b6d031abe01b467f18cb72d9 ]
      
      Currently the Book 3S KVM code uses kvm->lock to synchronize access
      to the kvm->arch.rtas_tokens list.  Because this list is scanned
      inside kvmppc_rtas_hcall(), which is called with the vcpu mutex held,
      taking kvm->lock cause a lock inversion problem, which could lead to
      a deadlock.
      
      To fix this, we add a new mutex, kvm->arch.rtas_token_lock, which nests
      inside the vcpu mutexes, and use that instead of kvm->lock when
      accessing the rtas token list.
      
      This removes the lockdep_assert_held() in kvmppc_rtas_tokens_free().
      At this point we don't hold the new mutex, but that is OK because
      kvmppc_rtas_tokens_free() is only called when the whole VM is being
      destroyed, and at that point nothing can be looking up a token in
      the list.
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      308a245a
    • Randy Dunlap's avatar
      ia64: fix build errors by exporting paddr_to_nid() · eb3be546
      Randy Dunlap authored
      [ Upstream commit 9a626c4a6326da4433a0d4d4a8a7d1571caf1ed3 ]
      
      Fix build errors on ia64 when DISCONTIGMEM=y and NUMA=y by
      exporting paddr_to_nid().
      
      Fixes these build errors:
      
      ERROR: "paddr_to_nid" [sound/core/snd-pcm.ko] undefined!
      ERROR: "paddr_to_nid" [net/sunrpc/sunrpc.ko] undefined!
      ERROR: "paddr_to_nid" [fs/cifs/cifs.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/video/fbdev/core/fb.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/usb/mon/usbmon.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/usb/core/usbcore.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/raid1.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-mod.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-crypt.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/md/dm-bufio.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/ide/ide-core.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/ide/ide-cd_mod.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/gpu/drm/drm.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/char/agp/agpgart.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/nbd.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/loop.ko] undefined!
      ERROR: "paddr_to_nid" [drivers/block/brd.ko] undefined!
      ERROR: "paddr_to_nid" [crypto/ccm.ko] undefined!
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      eb3be546
    • Thomas Richter's avatar
      perf record: Fix s390 missing module symbol and warning for non-root users · 810f6b9e
      Thomas Richter authored
      [ Upstream commit 6738028dd57df064b969d8392c943ef3b3ae705d ]
      
      Command 'perf record' and 'perf report' on a system without kernel
      debuginfo packages uses /proc/kallsyms and /proc/modules to find
      addresses for kernel and module symbols. On x86 this works for root and
      non-root users.
      
      On s390, when invoked as non-root user, many of the following warnings
      are shown and module symbols are missing:
      
          proc/{kallsyms,modules} inconsistency while looking for
              "[sha1_s390]" module!
      
      Command 'perf record' creates a list of module start addresses by
      parsing the output of /proc/modules and creates a PERF_RECORD_MMAP
      record for the kernel and each module. The following function call
      sequence is executed:
      
        machine__create_kernel_maps
          machine__create_module
            modules__parse
              machine__create_module --> for each line in /proc/modules
                arch__fix_module_text_start
      
      Function arch__fix_module_text_start() is s390 specific. It opens
      file /sys/module/<name>/sections/.text to extract the module's .text
      section start address. On s390 the module loader prepends a header
      before the first section, whereas on x86 the module's text section
      address is identical the the module's load address.
      
      However module section files are root readable only. For non-root the
      read operation fails and machine__create_module() returns an error.
      Command perf record does not generate any PERF_RECORD_MMAP record
      for loaded modules. Later command perf report complains about missing
      module maps.
      
      To fix this function arch__fix_module_text_start() always returns
      success. For root users there is no change, for non-root users
      the module's load address is used as module's text start address
      (the prepended header then counts as part of the text section).
      
      This enable non-root users to use module symbols and avoid the
      warning when perf report is executed.
      
      Output before:
      
        [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP
        0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text
      
      Output after:
      
        [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP
        0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text
        0 0x1b8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../autofs4.ko.xz
        0 0x250 [0xa8]: PERF_RECORD_MMAP ... x /lib/modules/.../sha_common.ko.xz
        0 0x2f8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../des_generic.ko.xz
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Link: http://lkml.kernel.org/r/20190522144601.50763-4-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      810f6b9e
    • Shawn Landden's avatar
      perf data: Fix 'strncat may truncate' build failure with recent gcc · 9c18909f
      Shawn Landden authored
      [ Upstream commit 97acec7df172cd1e450f81f5e293c0aa145a2797 ]
      
      This strncat() is safe because the buffer was allocated with zalloc(),
      however gcc doesn't know that. Since the string always has 4 non-null
      bytes, just use memcpy() here.
      
          CC       /home/shawn/linux/tools/perf/util/data-convert-bt.o
        In file included from /usr/include/string.h:494,
                         from /home/shawn/linux/tools/lib/traceevent/event-parse.h:27,
                         from util/data-convert-bt.c:22:
        In function ‘strncat’,
            inlined from ‘string_set_value’ at util/data-convert-bt.c:274:4:
        /usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation]
          136 |   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
              |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: default avatarShawn Landden <shawn@git.icu>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      LPU-Reference: 20190518183238.10954-1-shawn@git.icu
      Link: https://lkml.kernel.org/n/tip-289f1jice17ta7tr3tstm9jm@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9c18909f
    • Sahitya Tummala's avatar
      configfs: Fix use-after-free when accessing sd->s_dentry · 015cf9c6
      Sahitya Tummala authored
      [ Upstream commit f6122ed2a4f9c9c1c073ddf6308d1b2ac10e0781 ]
      
      In the vfs_statx() context, during path lookup, the dentry gets
      added to sd->s_dentry via configfs_attach_attr(). In the end,
      vfs_statx() kills the dentry by calling path_put(), which invokes
      configfs_d_iput(). Ideally, this dentry must be removed from
      sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result,
      sd->s_dentry is holding reference to a stale dentry pointer whose
      memory is already freed up. This results in use-after-free issue,
      when this stale sd->s_dentry is accessed later in
      configfs_readdir() path.
      
      This issue can be easily reproduced, by running the LTP test case -
      sh fs_racer_file_list.sh /config
      (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh)
      
      Fixes: 76ae281f ('configfs: fix race between dentry put and lookup')
      Signed-off-by: default avatarSahitya Tummala <stummala@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      015cf9c6
    • Bard Liao's avatar
      ALSA: hda - Force polling mode on CNL for fixing codec communication · 08c34c35
      Bard Liao authored
      [ Upstream commit fa763f1b2858752e6150ffff46886a1b7faffc82 ]
      
      We observed the same issue as reported by commit a8d7bde2
      ("ALSA: hda - Force polling mode on CFL for fixing codec communication")
      We don't have a better solution. So apply the same workaround to CNL.
      Signed-off-by: default avatarBard Liao <yung-chuan.liao@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      08c34c35
    • Yingjoe Chen's avatar
      i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr · 8bf2a244
      Yingjoe Chen authored
      [ Upstream commit a0692f0eef91354b62c2b4c94954536536be5425 ]
      
      If I2C_M_RECV_LEN check failed, msgs[i].buf allocated by memdup_user
      will not be freed. Pump index up so it will be freed.
      
      Fixes: 838bfa60 ("i2c-dev: Add support for I2C_M_RECV_LEN")
      Signed-off-by: default avatarYingjoe Chen <yingjoe.chen@mediatek.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8bf2a244
    • Dmitry Bogdanov's avatar
      net: aquantia: fix LRO with FCS error · d704ffa6
      Dmitry Bogdanov authored
      [ Upstream commit eaeb3b7494ba9159323814a8ce8af06a9277d99b ]
      
      Driver stops producing skbs on ring if a packet with FCS error
      was coalesced into LRO session. Ring gets hang forever.
      
      Thats a logical error in driver processing descriptors:
      When rx_stat indicates MAC Error, next pointer and eop flags
      are not filled. This confuses driver so it waits for descriptor 0
      to be filled by HW.
      
      Solution is fill next pointer and eop flag even for packets with FCS error.
      
      Fixes: bab6de8f ("net: ethernet: aquantia: Atlantic A0 and B0 specific functions.")
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarDmitry Bogdanov <dmitry.bogdanov@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d704ffa6
    • Kees Cook's avatar
      net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE() · 415c59fa
      Kees Cook authored
      [ Upstream commit 3e66b7cc50ef921121babc91487e1fb98af1ba6e ]
      
      Building with Clang reports the redundant use of MODULE_DEVICE_TABLE():
      
      drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table'
      MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
      ^
      ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
      extern typeof(name) __mod_##type##__##name##_device_table               \
                          ^
      <scratch space>:90:1: note: expanded from here
      __mod_eisa__de4x5_eisa_ids_device_table
      ^
      drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here
      MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
      ^
      ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
      extern typeof(name) __mod_##type##__##name##_device_table               \
                          ^
      <scratch space>:85:1: note: expanded from here
      __mod_eisa__de4x5_eisa_ids_device_table
      ^
      
      This drops the one further from the table definition to match the common
      use of MODULE_DEVICE_TABLE().
      
      Fixes: 07563c71 ("EISA bus MODALIAS attributes support")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      415c59fa
    • Randy Dunlap's avatar
      gpio: fix gpio-adp5588 build errors · 05d7bbbd
      Randy Dunlap authored
      [ Upstream commit e9646f0f5bb62b7d43f0968f39d536cfe7123b53 ]
      
      The gpio-adp5588 driver uses interfaces that are provided by
      GPIOLIB_IRQCHIP, so select that symbol in its Kconfig entry.
      
      Fixes these build errors:
      
      ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_handler’:
      ../drivers/gpio/gpio-adp5588.c:266:26: error: ‘struct gpio_chip’ has no member named ‘irq’
                  dev->gpio_chip.irq.domain, gpio));
                                ^
      ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_setup’:
      ../drivers/gpio/gpio-adp5588.c:298:2: error: implicit declaration of function ‘gpiochip_irqchip_add_nested’ [-Werror=implicit-function-declaration]
        ret = gpiochip_irqchip_add_nested(&dev->gpio_chip,
        ^
      ../drivers/gpio/gpio-adp5588.c:307:2: error: implicit declaration of function ‘gpiochip_set_nested_irqchip’ [-Werror=implicit-function-declaration]
        gpiochip_set_nested_irqchip(&dev->gpio_chip,
        ^
      
      Fixes: 459773ae ("gpio: adp5588-gpio: support interrupt controller")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: linux-gpio@vger.kernel.org
      Reviewed-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Acked-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      05d7bbbd
    • Peter Zijlstra's avatar
      perf/ring-buffer: Always use {READ,WRITE}_ONCE() for rb->user_page data · a9a83106
      Peter Zijlstra authored
      [ Upstream commit 4d839dd9e4356bbacf3eb0ab13a549b83b008c21 ]
      
      We must use {READ,WRITE}_ONCE() on rb->user_page data such that
      concurrent usage will see whole values. A few key sites were missing
      this.
      Suggested-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: acme@kernel.org
      Cc: mark.rutland@arm.com
      Cc: namhyung@kernel.org
      Fixes: 7b732a75 ("perf_counter: new output ABI - part 1")
      Link: http://lkml.kernel.org/r/20190517115418.394192145@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a9a83106
    • Peter Zijlstra's avatar
      perf/ring_buffer: Add ordering to rb->nest increment · 2bc92a4f
      Peter Zijlstra authored
      [ Upstream commit 3f9fbe9bd86c534eba2faf5d840fd44c6049f50e ]
      
      Similar to how decrementing rb->next too early can cause data_head to
      (temporarily) be observed to go backward, so too can this happen when
      we increment too late.
      
      This barrier() ensures the rb->head load happens after the increment,
      both the one in the 'goto again' path, as the one from
      perf_output_get_handle() -- albeit very unlikely to matter for the
      latter.
      Suggested-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: acme@kernel.org
      Cc: mark.rutland@arm.com
      Cc: namhyung@kernel.org
      Fixes: ef60777c ("perf: Optimize the perf_output() path by removing IRQ-disables")
      Link: http://lkml.kernel.org/r/20190517115418.309516009@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2bc92a4f
    • Yabin Cui's avatar
      perf/ring_buffer: Fix exposing a temporarily decreased data_head · 9e2de43b
      Yabin Cui authored
      [ Upstream commit 1b038c6e05ff70a1e66e3e571c2e6106bdb75f53 ]
      
      In perf_output_put_handle(), an IRQ/NMI can happen in below location and
      write records to the same ring buffer:
      
      	...
      	local_dec_and_test(&rb->nest)
      	...                          <-- an IRQ/NMI can happen here
      	rb->user_page->data_head = head;
      	...
      
      In this case, a value A is written to data_head in the IRQ, then a value
      B is written to data_head after the IRQ. And A > B. As a result,
      data_head is temporarily decreased from A to B. And a reader may see
      data_head < data_tail if it read the buffer frequently enough, which
      creates unexpected behaviors.
      
      This can be fixed by moving dec(&rb->nest) to after updating data_head,
      which prevents the IRQ/NMI above from updating data_head.
      
      [ Split up by peterz. ]
      Signed-off-by: default avatarYabin Cui <yabinc@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: mark.rutland@arm.com
      Fixes: ef60777c ("perf: Optimize the perf_output() path by removing IRQ-disables")
      Link: http://lkml.kernel.org/r/20190517115418.224478157@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9e2de43b
    • Frank van der Linden's avatar
      x86/CPU/AMD: Don't force the CPB cap when running under a hypervisor · 746b9c0c
      Frank van der Linden authored
      [ Upstream commit 2ac44ab608705948564791ce1d15d43ba81a1e38 ]
      
      For F17h AMD CPUs, the CPB capability ('Core Performance Boost') is forcibly set,
      because some versions of that chip incorrectly report that they do not have it.
      
      However, a hypervisor may filter out the CPB capability, for good
      reasons. For example, KVM currently does not emulate setting the CPB
      bit in MSR_K7_HWCR, and unchecked MSR access errors will be thrown
      when trying to set it as a guest:
      
      	unchecked MSR access error: WRMSR to 0xc0010015 (tried to write 0x0000000001000011) at rIP: 0xffffffff890638f4 (native_write_msr+0x4/0x20)
      
      	Call Trace:
      	boost_set_msr+0x50/0x80 [acpi_cpufreq]
      	cpuhp_invoke_callback+0x86/0x560
      	sort_range+0x20/0x20
      	cpuhp_thread_fun+0xb0/0x110
      	smpboot_thread_fn+0xef/0x160
      	kthread+0x113/0x130
      	kthread_create_worker_on_cpu+0x70/0x70
      	ret_from_fork+0x35/0x40
      
      To avoid this issue, don't forcibly set the CPB capability for a CPU
      when running under a hypervisor.
      Signed-off-by: default avatarFrank van der Linden <fllinden@amazon.com>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: jiaxun.yang@flygoat.com
      Fixes: 0237199186e7 ("x86/CPU/AMD: Set the CPB bit unconditionally on F17h")
      Link: http://lkml.kernel.org/r/20190522221745.GA15789@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com
      [ Minor edits to the changelog. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      746b9c0c
    • Dan Carpenter's avatar
      mISDN: make sure device name is NUL terminated · dca534e3
      Dan Carpenter authored
      [ Upstream commit ccfb62f27beb295103e9392462b20a6ed807d0ea ]
      
      The user can change the device_name with the IMSETDEVNAME ioctl, but we
      need to ensure that the user's name is NUL terminated.  Otherwise it
      could result in a buffer overflow when we copy the name back to the user
      with IMGETDEVINFO ioctl.
      
      I also changed two strcpy() calls which handle the name to strscpy().
      Hopefully, there aren't any other ways to create a too long name, but
      it's nice to do this as a kernel hardening measure.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dca534e3
    • Anju T Sudhakar's avatar
      powerpc/powernv: Return for invalid IMC domain · 8a58d4a2
      Anju T Sudhakar authored
      [ Upstream commit b59bd3527fe3c1939340df558d7f9d568fc9f882 ]
      
      Currently init_imc_pmu() can fail either because we try to register an
      IMC unit with an invalid domain (i.e an IMC node not supported by the
      kernel) or something went wrong while registering a valid IMC unit. In
      both the cases kernel provides a 'Register failed' error message.
      
      For example when trace-imc node is not supported by the kernel, but
      skiboot advertises a trace-imc node we print:
      
        IMC Unknown Device type
        IMC PMU (null) Register failed
      
      To avoid confusion just print the unknown device type message, before
      attempting PMU registration, so the second message isn't printed.
      
      Fixes: 8f95faaa ("powerpc/powernv: Detect and create IMC device")
      Reported-by: default avatarPavaman Subramaniyam <pavsubra@in.ibm.com>
      Signed-off-by: default avatarAnju T Sudhakar <anju@linux.vnet.ibm.com>
      Reviewed-by: default avatarMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      [mpe: Reword change log a bit]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8a58d4a2
    • Tony Lindgren's avatar
      clk: ti: clkctrl: Fix clkdm_clk handling · 535e73cd
      Tony Lindgren authored
      [ Upstream commit 1cc54078d104f5b4d7e9f8d55362efa5a8daffdb ]
      
      We need to always call clkdm_clk_enable() and clkdm_clk_disable() even
      the clkctrl clock(s) enabled for the domain do not have any gate register
      bits. Otherwise clockdomains may never get enabled except when devices get
      probed with the legacy "ti,hwmods" devicetree property.
      
      Fixes: 88a17252 ("clk: ti: add support for clkctrl clocks")
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      535e73cd
    • Jeffrin Jose T's avatar
      selftests: netfilter: missing error check when setting up veth interface · b22ab51a
      Jeffrin Jose T authored
      [ Upstream commit 82ce6eb1dd13fd12e449b2ee2c2ec051e6f52c43 ]
      
      A test for the basic NAT functionality uses ip command which needs veth
      device. There is a condition where the kernel support for veth is not
      compiled into the kernel and the test script breaks. This patch contains
      code for reasonable error display and correct code exit.
      Signed-off-by: default avatarJeffrin Jose T <jeffrin@rajagiritech.edu.in>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b22ab51a
    • YueHaibing's avatar
      ipvs: Fix use-after-free in ip_vs_in · 72634d7f
      YueHaibing authored
      [ Upstream commit 719c7d563c17b150877cee03a4b812a424989dfa ]
      
      BUG: KASAN: use-after-free in ip_vs_in.part.29+0xe8/0xd20 [ip_vs]
      Read of size 4 at addr ffff8881e9b26e2c by task sshd/5603
      
      CPU: 0 PID: 5603 Comm: sshd Not tainted 4.19.39+ #30
      Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      Call Trace:
       dump_stack+0x71/0xab
       print_address_description+0x6a/0x270
       kasan_report+0x179/0x2c0
       ip_vs_in.part.29+0xe8/0xd20 [ip_vs]
       ip_vs_in+0xd8/0x170 [ip_vs]
       nf_hook_slow+0x5f/0xe0
       __ip_local_out+0x1d5/0x250
       ip_local_out+0x19/0x60
       __tcp_transmit_skb+0xba1/0x14f0
       tcp_write_xmit+0x41f/0x1ed0
       ? _copy_from_iter_full+0xca/0x340
       __tcp_push_pending_frames+0x52/0x140
       tcp_sendmsg_locked+0x787/0x1600
       ? tcp_sendpage+0x60/0x60
       ? inet_sk_set_state+0xb0/0xb0
       tcp_sendmsg+0x27/0x40
       sock_sendmsg+0x6d/0x80
       sock_write_iter+0x121/0x1c0
       ? sock_sendmsg+0x80/0x80
       __vfs_write+0x23e/0x370
       vfs_write+0xe7/0x230
       ksys_write+0xa1/0x120
       ? __ia32_sys_read+0x50/0x50
       ? __audit_syscall_exit+0x3ce/0x450
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7ff6f6147c60
      Code: 73 01 c3 48 8b 0d 28 12 2d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 5d 73 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83
      RSP: 002b:00007ffd772ead18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000034 RCX: 00007ff6f6147c60
      RDX: 0000000000000034 RSI: 000055df30a31270 RDI: 0000000000000003
      RBP: 000055df30a31270 R08: 0000000000000000 R09: 0000000000000000
      R10: 00007ffd772ead70 R11: 0000000000000246 R12: 00007ffd772ead74
      R13: 00007ffd772eae20 R14: 00007ffd772eae24 R15: 000055df2f12ddc0
      
      Allocated by task 6052:
       kasan_kmalloc+0xa0/0xd0
       __kmalloc+0x10a/0x220
       ops_init+0x97/0x190
       register_pernet_operations+0x1ac/0x360
       register_pernet_subsys+0x24/0x40
       0xffffffffc0ea016d
       do_one_initcall+0x8b/0x253
       do_init_module+0xe3/0x335
       load_module+0x2fc0/0x3890
       __do_sys_finit_module+0x192/0x1c0
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 6067:
       __kasan_slab_free+0x130/0x180
       kfree+0x90/0x1a0
       ops_free_list.part.7+0xa6/0xc0
       unregister_pernet_operations+0x18b/0x1f0
       unregister_pernet_subsys+0x1d/0x30
       ip_vs_cleanup+0x1d/0xd2f [ip_vs]
       __x64_sys_delete_module+0x20c/0x300
       do_syscall_64+0x73/0x200
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff8881e9b26600 which belongs to the cache kmalloc-4096 of size 4096
      The buggy address is located 2092 bytes inside of 4096-byte region [ffff8881e9b26600, ffff8881e9b27600)
      The buggy address belongs to the page:
      page:ffffea0007a6c800 count:1 mapcount:0 mapping:ffff888107c0e600 index:0x0 compound_mapcount: 0
      flags: 0x17ffffc0008100(slab|head)
      raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff888107c0e600
      raw: 0000000000000000 0000000080070007 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      while unregistering ipvs module, ops_free_list calls
      __ip_vs_cleanup, then nf_unregister_net_hooks be called to
      do remove nf hook entries. It need a RCU period to finish,
      however net->ipvs is set to NULL immediately, which will
      trigger NULL pointer dereference when a packet is hooked
      and handled by ip_vs_in where net->ipvs is dereferenced.
      
      Another scene is ops_free_list call ops_free to free the
      net_generic directly while __ip_vs_cleanup finished, then
      calling ip_vs_in will triggers use-after-free.
      
      This patch moves nf_unregister_net_hooks from __ip_vs_cleanup()
      to __ip_vs_dev_cleanup(),  where rcu_barrier() is called by
      unregister_pernet_device -> unregister_pernet_operations,
      that will do the needed grace period.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: efe41606 ("ipvs: convert to use pernet nf_hook api")
      Suggested-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      72634d7f
    • Jagdish Motwani's avatar
      netfilter: nf_queue: fix reinject verdict handling · 20e4ded1
      Jagdish Motwani authored
      [ Upstream commit 946c0d8e6ed43dae6527e878d0077c1e11015db0 ]
      
      This patch fixes netfilter hook traversal when there are more than 1 hooks
      returning NF_QUEUE verdict. When the first queue reinjects the packet,
      'nf_reinject' starts traversing hooks with a proper hook_index. However,
      if it again receives a NF_QUEUE verdict (by some other netfilter hook), it
      queues the packet with a wrong hook_index. So, when the second queue
      reinjects the packet, it re-executes hooks in between.
      
      Fixes: 960632ec ("netfilter: convert hook list to an array")
      Signed-off-by: default avatarJagdish Motwani <jagdish.motwani@sophos.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      20e4ded1
    • Stephane Eranian's avatar
      perf/x86/intel/ds: Fix EVENT vs. UEVENT PEBS constraints · 8309ce74
      Stephane Eranian authored
      [ Upstream commit 23e3983a466cd540ffdd2bbc6e0c51e31934f941 ]
      
      This patch fixes an bug revealed by the following commit:
      
        6b89d4c1ae85 ("perf/x86/intel: Fix INTEL_FLAGS_EVENT_CONSTRAINT* masking")
      
      That patch modified INTEL_FLAGS_EVENT_CONSTRAINT() to only look at the event code
      when matching a constraint. If code+umask were needed, then the
      INTEL_FLAGS_UEVENT_CONSTRAINT() macro was needed instead.
      This broke with some of the constraints for PEBS events.
      
      Several of them, including the one used for cycles:p, cycles:pp, cycles:ppp
      fell in that category and caused the event to be rejected in PEBS mode.
      In other words, on some platforms a cmdline such as:
      
        $ perf top -e cycles:pp
      
      would fail with -EINVAL.
      
      This patch fixes this bug by properly using INTEL_FLAGS_UEVENT_CONSTRAINT()
      when needed in the PEBS constraint tables.
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: kan.liang@intel.com
      Link: http://lkml.kernel.org/r/20190521005246.423-1-eranian@google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8309ce74
    • Dan Carpenter's avatar
      Staging: vc04_services: Fix a couple error codes · f1c62cdf
      Dan Carpenter authored
      [ Upstream commit ca4e4efbefbbdde0a7bb3023ea08d491f4daf9b9 ]
      
      These are accidentally returning positive EINVAL instead of negative
      -EINVAL.  Some of the callers treat positive values as success.
      
      Fixes: 7b3ad5ab ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f1c62cdf
    • John Paul Adrian Glaubitz's avatar
      sunhv: Fix device naming inconsistency between sunhv_console and sunhv_reg · 155656d0
      John Paul Adrian Glaubitz authored
      [ Upstream commit 07a6d63eb1b54b5fb38092780fe618dfe1d96e23 ]
      
      In d5a2aa24, the name in struct console sunhv_console was changed from "ttyS"
      to "ttyHV" while the name in struct uart_ops sunhv_pops remained unchanged.
      
      This results in the hypervisor console device to be listed as "ttyHV0" under
      /proc/consoles while the device node is still named "ttyS0":
      
      root@osaka:~# cat /proc/consoles
      ttyHV0               -W- (EC p  )    4:64
      tty0                 -WU (E     )    4:1
      root@osaka:~# readlink /sys/dev/char/4:64
      ../../devices/root/f02836f0/f0285690/tty/ttyS0
      root@osaka:~#
      
      This means that any userland code which tries to determine the name of the
      device file of the hypervisor console device can not rely on the information
      provided by /proc/consoles. In particular, booting current versions of debian-
      installer inside a SPARC LDOM will fail with the installer unable to determine
      the console device.
      
      After renaming the device in struct uart_ops sunhv_pops to "ttyHV" as well,
      the inconsistency is fixed and it is possible again to determine the name
      of the device file of the hypervisor console device by reading the contents
      of /proc/console:
      
      root@osaka:~# cat /proc/consoles
      ttyHV0               -W- (EC p  )    4:64
      tty0                 -WU (E     )    4:1
      root@osaka:~# readlink /sys/dev/char/4:64
      ../../devices/root/f02836f0/f0285690/tty/ttyHV0
      root@osaka:~#
      
      With this change, debian-installer works correctly when installing inside
      a SPARC LDOM.
      Signed-off-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      155656d0
    • Neil Horman's avatar
      sctp: Free cookie before we memdup a new one · c4964bfa
      Neil Horman authored
      [ Upstream commit ce950f1050cece5e406a5cde723c69bba60e1b26 ]
      
      Based on comments from Xin, even after fixes for our recent syzbot
      report of cookie memory leaks, its possible to get a resend of an INIT
      chunk which would lead to us leaking cookie memory.
      
      To ensure that we don't leak cookie memory, free any previously
      allocated cookie first.
      
      Change notes
      v1->v2
      update subsystem tag in subject (davem)
      repeat kfree check for peer_random and peer_hmacs (xin)
      
      v2->v3
      net->sctp
      also free peer_chunks
      
      v3->v4
      fix subject tags
      
      v4->v5
      remove cut line
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com
      CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      CC: Xin Long <lucien.xin@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4964bfa
    • Taehee Yoo's avatar
      net: openvswitch: do not free vport if register_netdevice() is failed. · 60086c37
      Taehee Yoo authored
      [ Upstream commit 309b66970ee2abf721ecd0876a48940fa0b99a35 ]
      
      In order to create an internal vport, internal_dev_create() is used and
      that calls register_netdevice() internally.
      If register_netdevice() fails, it calls dev->priv_destructor() to free
      private data of netdev. actually, a private data of this is a vport.
      
      Hence internal_dev_create() should not free and use a vport after failure
      of register_netdevice().
      
      Test command
          ovs-dpctl add-dp bonding_masters
      
      Splat looks like:
      [ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory access
      [ 1035.675958] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: G    B             5.2.0-rc3+ #240
      [ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch]
      [ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4
      [ 1035.713720] RSP: 0018:ffff88810dcb7578 EFLAGS: 00010206
      [ 1035.713720] RAX: dffffc0000000000 RBX: ffff88810d13fe08 RCX: ffffffff84297704
      [ 1035.713720] RDX: 00000000000000ac RSI: 0000000000000000 RDI: 0000000000000560
      [ 1035.713720] RBP: 00000000ffffffef R08: fffffbfff0d3b881 R09: fffffbfff0d3b881
      [ 1035.713720] R10: 0000000000000001 R11: fffffbfff0d3b880 R12: 0000000000000000
      [ 1035.768776] R13: 0000607ee460b900 R14: ffff88810dcb7690 R15: ffff88810dcb7698
      [ 1035.777709] FS:  00007f02095fc980(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000
      [ 1035.777709] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1035.777709] CR2: 00007ffdf01d2f28 CR3: 0000000108258000 CR4: 00000000001006e0
      [ 1035.777709] Call Trace:
      [ 1035.777709]  ovs_vport_add+0x267/0x4f0 [openvswitch]
      [ 1035.777709]  new_vport+0x15/0x1e0 [openvswitch]
      [ 1035.777709]  ovs_vport_cmd_new+0x567/0xd10 [openvswitch]
      [ 1035.777709]  ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch]
      [ 1035.777709]  ? __kmalloc+0x131/0x2e0
      [ 1035.777709]  ? genl_family_rcv_msg+0xa54/0x1030
      [ 1035.777709]  genl_family_rcv_msg+0x63a/0x1030
      [ 1035.777709]  ? genl_unregister_family+0x630/0x630
      [ 1035.841681]  ? debug_show_all_locks+0x2d0/0x2d0
      [ ... ]
      
      Fixes: cf124db5 ("net: Fix inconsistent teardown and release of private netdev state.")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60086c37
    • Eric Dumazet's avatar
      neigh: fix use-after-free read in pneigh_get_next · a7d1e0ea
      Eric Dumazet authored
      [ Upstream commit f3e92cb8e2eb8c27d109e6fd73d3a69a8c09e288 ]
      
      Nine years ago, I added RCU handling to neighbours, not pneighbours.
      (pneigh are not commonly used)
      
      Unfortunately I missed that /proc dump operations would use a
      common entry and exit point : neigh_seq_start() and neigh_seq_stop()
      
      We need to read_lock(tbl->lock) or risk use-after-free while
      iterating the pneigh structures.
      
      We might later convert pneigh to RCU and revert this patch.
      
      sysbot reported :
      
      BUG: KASAN: use-after-free in pneigh_get_next.isra.0+0x24b/0x280 net/core/neighbour.c:3158
      Read of size 8 at addr ffff888097f2a700 by task syz-executor.0/9825
      
      CPU: 1 PID: 9825 Comm: syz-executor.0 Not tainted 5.2.0-rc4+ #32
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
       pneigh_get_next.isra.0+0x24b/0x280 net/core/neighbour.c:3158
       neigh_seq_next+0xdb/0x210 net/core/neighbour.c:3240
       seq_read+0x9cf/0x1110 fs/seq_file.c:258
       proc_reg_read+0x1fc/0x2c0 fs/proc/inode.c:221
       do_loop_readv_writev fs/read_write.c:714 [inline]
       do_loop_readv_writev fs/read_write.c:701 [inline]
       do_iter_read+0x4a4/0x660 fs/read_write.c:935
       vfs_readv+0xf0/0x160 fs/read_write.c:997
       kernel_readv fs/splice.c:359 [inline]
       default_file_splice_read+0x475/0x890 fs/splice.c:414
       do_splice_to+0x127/0x180 fs/splice.c:877
       splice_direct_to_actor+0x2d2/0x970 fs/splice.c:954
       do_splice_direct+0x1da/0x2a0 fs/splice.c:1063
       do_sendfile+0x597/0xd00 fs/read_write.c:1464
       __do_sys_sendfile64 fs/read_write.c:1525 [inline]
       __se_sys_sendfile64 fs/read_write.c:1511 [inline]
       __x64_sys_sendfile64+0x1dd/0x220 fs/read_write.c:1511
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4592c9
      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:00007f4aab51dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
      RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00000000004592c9
      RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000005
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000080000000 R11: 0000000000000246 R12: 00007f4aab51e6d4
      R13: 00000000004c689d R14: 00000000004db828 R15: 00000000ffffffff
      
      Allocated by task 9827:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_kmalloc mm/kasan/common.c:489 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
       __do_kmalloc mm/slab.c:3660 [inline]
       __kmalloc+0x15c/0x740 mm/slab.c:3669
       kmalloc include/linux/slab.h:552 [inline]
       pneigh_lookup+0x19c/0x4a0 net/core/neighbour.c:731
       arp_req_set_public net/ipv4/arp.c:1010 [inline]
       arp_req_set+0x613/0x720 net/ipv4/arp.c:1026
       arp_ioctl+0x652/0x7f0 net/ipv4/arp.c:1226
       inet_ioctl+0x2a0/0x340 net/ipv4/af_inet.c:926
       sock_do_ioctl+0xd8/0x2f0 net/socket.c:1043
       sock_ioctl+0x3ed/0x780 net/socket.c:1194
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:509 [inline]
       do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
       ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl fs/ioctl.c:718 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 9824:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
       __cache_free mm/slab.c:3432 [inline]
       kfree+0xcf/0x220 mm/slab.c:3755
       pneigh_ifdown_and_unlock net/core/neighbour.c:812 [inline]
       __neigh_ifdown+0x236/0x2f0 net/core/neighbour.c:356
       neigh_ifdown+0x20/0x30 net/core/neighbour.c:372
       arp_ifdown+0x1d/0x21 net/ipv4/arp.c:1274
       inetdev_destroy net/ipv4/devinet.c:319 [inline]
       inetdev_event+0xa14/0x11f0 net/ipv4/devinet.c:1544
       notifier_call_chain+0xc2/0x230 kernel/notifier.c:95
       __raw_notifier_call_chain kernel/notifier.c:396 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1749
       call_netdevice_notifiers_extack net/core/dev.c:1761 [inline]
       call_netdevice_notifiers net/core/dev.c:1775 [inline]
       rollback_registered_many+0x9b9/0xfc0 net/core/dev.c:8178
       rollback_registered+0x109/0x1d0 net/core/dev.c:8220
       unregister_netdevice_queue net/core/dev.c:9267 [inline]
       unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9260
       unregister_netdevice include/linux/netdevice.h:2631 [inline]
       __tun_detach+0xd8a/0x1040 drivers/net/tun.c:724
       tun_detach drivers/net/tun.c:741 [inline]
       tun_chr_close+0xe0/0x180 drivers/net/tun.c:3451
       __fput+0x2ff/0x890 fs/file_table.c:280
       ____fput+0x16/0x20 fs/file_table.c:313
       task_work_run+0x145/0x1c0 kernel/task_work.c:113
       tracehook_notify_resume include/linux/tracehook.h:185 [inline]
       exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:168
       prepare_exit_to_usermode arch/x86/entry/common.c:199 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:279 [inline]
       do_syscall_64+0x58e/0x680 arch/x86/entry/common.c:304
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff888097f2a700
       which belongs to the cache kmalloc-64 of size 64
      The buggy address is located 0 bytes inside of
       64-byte region [ffff888097f2a700, ffff888097f2a740)
      The buggy address belongs to the page:
      page:ffffea00025fca80 refcount:1 mapcount:0 mapping:ffff8880aa400340 index:0x0
      flags: 0x1fffc0000000200(slab)
      raw: 01fffc0000000200 ffffea000250d548 ffffea00025726c8 ffff8880aa400340
      raw: 0000000000000000 ffff888097f2a000 0000000100000020 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888097f2a600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
       ffff888097f2a680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      >ffff888097f2a700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
                         ^
       ffff888097f2a780: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff888097f2a800: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      
      Fixes: 767e97e1 ("neigh: RCU conversion of struct neighbour")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7d1e0ea
    • Jeremy Sowden's avatar
      lapb: fixed leak of control-blocks. · f0662be0
      Jeremy Sowden authored
      [ Upstream commit 6be8e297f9bcea666ea85ac7a6cd9d52d6deaf92 ]
      
      lapb_register calls lapb_create_cb, which initializes the control-
      block's ref-count to one, and __lapb_insert_cb, which increments it when
      adding the new block to the list of blocks.
      
      lapb_unregister calls __lapb_remove_cb, which decrements the ref-count
      when removing control-block from the list of blocks, and calls lapb_put
      itself to decrement the ref-count before returning.
      
      However, lapb_unregister also calls __lapb_devtostruct to look up the
      right control-block for the given net_device, and __lapb_devtostruct
      also bumps the ref-count, which means that when lapb_unregister returns
      the ref-count is still 1 and the control-block is leaked.
      
      Call lapb_put after __lapb_devtostruct to fix leak.
      
      Reported-by: syzbot+afb980676c836b4a0afa@syzkaller.appspotmail.com
      Signed-off-by: default avatarJeremy Sowden <jeremy@azazel.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0662be0
    • Eric Dumazet's avatar
      ipv6: flowlabel: fl6_sock_lookup() must use atomic_inc_not_zero · 3cc4e63c
      Eric Dumazet authored
      [ Upstream commit 65a3c497c0e965a552008db8bc2653f62bc925a1 ]
      
      Before taking a refcount, make sure the object is not already
      scheduled for deletion.
      
      Same fix is needed in ipv6_flowlabel_opt()
      
      Fixes: 18367681 ("ipv6 flowlabel: Convert np->ipv6_fl_list to RCU.")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3cc4e63c