1. 22 Jun, 2019 40 commits
    • Alexander Lochmann's avatar
      Abort file_remove_privs() for non-reg. files · 2c546242
      Alexander Lochmann authored
      commit f69e749a
      
       upstream.
      
      file_remove_privs() might be called for non-regular files, e.g.
      blkdev inode. There is no reason to do its job on things
      like blkdev inodes, pipes, or cdevs. Hence, abort if
      file does not refer to a regular inode.
      
      AV: more to the point, for devices there might be any number of
      inodes refering to given device.  Which one to strip the permissions
      from, even if that made any sense in the first place?  All of them
      will be observed with contents modified, after all.
      
      Found by LockDoc (Alexander Lochmann, Horst Schirmeier and Olaf
      Spinczyk)
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAlexander Lochmann <alexander.lochmann@tu-dortmund.de>
      Signed-off-by: default avatarHorst Schirmeier <horst.schirmeier@tu-dortmund.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Zubin Mithra <zsm@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c546242
    • Ajay Kaher's avatar
      infiniband: fix race condition between infiniband mlx4, mlx5 driver and core dumping · 7ab0cb70
      Ajay Kaher authored
      This patch is the extension of following upstream commit to fix
      the race condition between get_task_mm() and core dumping
      for IB->mlx4 and IB->mlx5 drivers:
      
      commit 04f5866e
      
       ("coredump: fix race condition between
      mmget_not_zero()/get_task_mm() and core dumping")'
      
      Thanks to Jason for pointing this.
      Signed-off-by: default avatarAjay Kaher <akaher@vmware.com>
      Acked-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      7ab0cb70
    • Andrea Arcangeli's avatar
      coredump: fix race condition between collapse_huge_page() and core dumping · dc30d2ce
      Andrea Arcangeli authored
      commit 59ea6d06 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 04f5866e ("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 fe7f8d73 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 e92a7be7 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 2cc08800 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 275e928f ]
      
      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 3b054179 ]
      
      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 12e750bc
      
       ]
      
      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 1d94f06e
      
       ]
      
      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 cc555759
      
       ]
      
      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 2b892649 ]
      
      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 315ca92d
      
       ]
      
      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 5a3f4936
      
       ]
      
      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 1659e27d
      
       ]
      
      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 9a626c4a
      
       ]
      
      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 6738028d
      
       ]
      
      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.com
      
      Signed-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 97acec7d
      
       ]
      
      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.org
      
      Signed-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 f6122ed2 ]
      
      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 fa763f1b ]
      
      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 a0692f0e ]
      
      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 eaeb3b74 ]
      
      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 3e66b7cc ]
      
      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 e9646f0f ]
      
      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 4d839dd9
      
       ]
      
      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.org
      
      Signed-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 3f9fbe9b
      
       ]
      
      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.org
      
      Signed-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 1b038c6e
      
       ]
      
      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.org
      
      Signed-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 2ac44ab6
      
       ]
      
      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: 02371991 ("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 ccfb62f2
      
       ]
      
      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 b59bd352 ]
      
      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 1cc54078 ]
      
      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 82ce6eb1
      
       ]
      
      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 719c7d56
      
       ]
      
      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 946c0d8e ]
      
      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 23e3983a ]
      
      This patch fixes an bug revealed by the following commit:
      
        6b89d4c1
      
       ("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.com
      
      Signed-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 ca4e4efb ]
      
      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 07a6d63e ]
      
      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 ce950f10
      
       ]
      
      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 309b6697 ]
      
      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 f3e92cb8 ]
      
      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