Skip to content
Snippets Groups Projects
  1. Jun 30, 2021
    • Francesco Ruggeri's avatar
      ipv6: record frag_max_size in atomic fragments in input path · d1fd69d9
      Francesco Ruggeri authored
      
      stable inclusion
      from linux-4.19.193
      commit ea9ef822d541859b65696b62647ccc4ab43c1129
      
      --------------------------------
      
      [ Upstream commit e29f011e8fc04b2cdc742a2b9bbfa1b62518381a ]
      
      Commit dbd1759e ("ipv6: on reassembly, record frag_max_size")
      filled the frag_max_size field in IP6CB in the input path.
      The field should also be filled in case of atomic fragments.
      
      Fixes: dbd1759e ('ipv6: on reassembly, record frag_max_size')
      Signed-off-by: default avatarFrancesco Ruggeri <fruggeri@arista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      d1fd69d9
    • Dan Carpenter's avatar
      scsi: libsas: Use _safe() loop in sas_resume_port() · 7058e08c
      Dan Carpenter authored
      stable inclusion
      from linux-4.19.193
      commit 94e2701600ecc5505d4727d580c83b66ecc80ec7
      
      --------------------------------
      
      [ Upstream commit 8c7e7b8486cda21269d393245883c5e4737d5ee7 ]
      
      If sas_notify_lldd_dev_found() fails then this code calls:
      
      	sas_unregister_dev(port, dev);
      
      which removes "dev", our list iterator, from the list.  This could lead to
      an endless loop.  We need to use list_for_each_entry_safe().
      
      Link: https://lore.kernel.org/r/YKUeq6gwfGcvvhty@mwanda
      
      
      Fixes: 303694ee ("[SCSI] libsas: suspend / resume support")
      Reviewed-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      7058e08c
    • Steve French's avatar
      SMB3: incorrect file id in requests compounded with open · 1f1faf21
      Steve French authored
      
      stable inclusion
      from linux-4.19.193
      commit 66988dc4dc62adf9d86e8f1e844fc747bbee28b7
      
      --------------------------------
      
      [ Upstream commit c0d46717b95735b0eacfddbcca9df37a49de9c7a ]
      
      See MS-SMB2 3.2.4.1.4, file ids in compounded requests should be set to
      0xFFFFFFFFFFFFFFFF (we were treating it as u32 not u64 and setting
      it incorrectly).
      
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reported-by: default avatarStefan Metzmacher <metze@samba.org>
      Reviewed-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      1f1faf21
    • Zhang Xiaoxu's avatar
      NFSv4: Fix v4.0/v4.1 SEEK_DATA return -ENOTSUPP when set NFS_V4_2 config · 09e16905
      Zhang Xiaoxu authored
      
      stable inclusion
      from linux-4.19.193
      commit 1cfca6c32c2a6c41370010fcc4067e2d8dcfa02b
      
      --------------------------------
      
      commit e67afa7ee4a59584d7253e45d7f63b9528819a13 upstream.
      
      Since commit bdcc2cd1 ("NFSv4.2: handle NFS-specific llseek errors"),
      nfs42_proc_llseek would return -EOPNOTSUPP rather than -ENOTSUPP when
      SEEK_DATA on NFSv4.0/v4.1.
      
      This will lead xfstests generic/285 not run on NFSv4.0/v4.1 when set the
      CONFIG_NFS_V4_2, rather than run failed.
      
      Fixes: bdcc2cd1 ("NFSv4.2: handle NFS-specific llseek errors")
      Cc: <stable.vger.kernel.org> # 4.2
      Signed-off-by: default avatarZhang Xiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      09e16905
    • Trond Myklebust's avatar
      NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce() · ae8cddd2
      Trond Myklebust authored
      
      stable inclusion
      from linux-4.19.193
      commit 40f139a6d50c232c0d1fd1c5e65a845c62db0ede
      
      --------------------------------
      
      commit 0d0ea309357dea0d85a82815f02157eb7fcda39f upstream.
      
      The value of mirror->pg_bytes_written should only be updated after a
      successful attempt to flush out the requests on the list.
      
      Fixes: a7d42ddb ("nfs: add mirroring support to pgio layer")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      ae8cddd2
    • Dan Carpenter's avatar
      NFS: fix an incorrect limit in filelayout_decode_layout() · 08894b9a
      Dan Carpenter authored
      
      stable inclusion
      from linux-4.19.193
      commit 945ebef997227ca8c20bad7f8a8358c8ee57a84a
      
      --------------------------------
      
      commit 769b01ea68b6c49dc3cde6adf7e53927dacbd3a8 upstream.
      
      The "sizeof(struct nfs_fh)" is two bytes too large and could lead to
      memory corruption.  It should be NFS_MAXFHSIZE because that's the size
      of the ->data[] buffer.
      
      I reversed the size of the arguments to put the variable on the left.
      
      Fixes: 16b374ca ("NFSv4.1: pnfs: filelayout: add driver's LAYOUTGET and GETDEVICEINFO infrastructure")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      08894b9a
    • Mikulas Patocka's avatar
      dm snapshot: properly fix a crash when an origin has no snapshots · 72598ced
      Mikulas Patocka authored
      
      stable inclusion
      from linux-4.19.193
      commit 3fe7be3c1d77af7038ebb3d4972b00ebea5f8183
      
      --------------------------------
      
      commit 7e768532b2396bcb7fbf6f82384b85c0f1d2f197 upstream.
      
      If an origin target has no snapshots, o->split_boundary is set to 0.
      This causes BUG_ON(sectors <= 0) in block/bio.c:bio_split().
      
      Fix this by initializing chunk_size, and in turn split_boundary, to
      rounddown_pow_of_two(UINT_MAX) -- the largest power of two that fits
      into "unsigned" type.
      
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      72598ced
    • Kees Cook's avatar
      proc: Check /proc/$pid/attr/ writes against file opener · 7e5b8f0a
      Kees Cook authored
      stable inclusion
      from linux-4.19.193
      commit 582a9b9813ecc89a3b5944ea412f383d02904c50
      
      --------------------------------
      
      commit bfb819ea20ce8bbeeba17e1a6418bf8bda91fc28 upstream.
      
      Fix another "confused deputy" weakness[1]. Writes to /proc/$pid/attr/
      files need to check the opener credentials, since these fds do not
      transition state across execve(). Without this, it is possible to
      trick another process (which may have different credentials) to write
      to its own /proc/$pid/attr/ files, leading to unexpected and possibly
      exploitable behaviors.
      
      [1] https://www.kernel.org/doc/html/latest/security/credentials.html?highlight=confused#open-file-credentials
      
      
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      7e5b8f0a
    • Rolf Eike Beer's avatar
      iommu/vt-d: Fix sysfs leak in alloc_iommu() · 5a5dba84
      Rolf Eike Beer authored
      
      stable inclusion
      from linux-4.19.193
      commit 2ec5e9bb6b0560c90d315559c28a99723c80b996
      
      --------------------------------
      
      commit 0ee74d5a48635c848c20f152d0d488bf84641304 upstream.
      
      iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequent
      errors.
      
      Fixes: 39ab9555 ("iommu: Add sysfs bindings for struct iommu_device")
      Cc: stable@vger.kernel.org # 4.11.x
      Signed-off-by: default avatarRolf Eike Beer <eb@emlix.com>
      Acked-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Link: https://lore.kernel.org/r/17411490.HIIP88n32C@mobilepool36.emlix.com
      Link: https://lore.kernel.org/r/20210525070802.361755-2-baolu.lu@linux.intel.com
      
      
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      5a5dba84
    • Anna Schumaker's avatar
      NFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return() · 119ed4a9
      Anna Schumaker authored
      
      stable inclusion
      from linux-4.19.193
      commit 39785761feadf261bc5101372b0b0bbaf6a94494
      
      --------------------------------
      
      commit a421d218603ffa822a0b8045055c03eae394a7eb upstream.
      
      Commit de144ff4234f changes _pnfs_return_layout() to call
      pnfs_mark_matching_lsegs_return() passing NULL as the struct
      pnfs_layout_range argument. Unfortunately,
      pnfs_mark_matching_lsegs_return() doesn't check if we have a value here
      before dereferencing it, causing an oops.
      
      I'm able to hit this crash consistently when running connectathon basic
      tests on NFS v4.1/v4.2 against Ontap.
      
      Fixes: de144ff4234f ("NFSv4: Don't discard segments marked for return in _pnfs_return_layout()")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      119ed4a9
    • Aurelien Aptel's avatar
      cifs: set server->cipher_type to AES-128-CCM for SMB3.0 · caa2e7c7
      Aurelien Aptel authored
      
      stable inclusion
      from linux-4.19.193
      commit d094067852cd1eefbcdc3c110c69265b6ce8c981
      
      --------------------------------
      
      commit 6d2fcfe6b517fe7cbf2687adfb0a16cdcd5d9243 upstream.
      
      SMB3.0 doesn't have encryption negotiate context but simply uses
      the SMB2_GLOBAL_CAP_ENCRYPTION flag.
      
      When that flag is present in the neg response cifs.ko uses AES-128-CCM
      which is the only cipher available in this context.
      
      cipher_type was set to the server cipher only when parsing encryption
      negotiate context (SMB3.1.1).
      
      For SMB3.0 it was set to 0. This means cipher_type value can be 0 or 1
      for AES-128-CCM.
      
      Fix this by checking for SMB3.0 and encryption capability and setting
      cipher_type appropriately.
      
      Signed-off-by: default avatarAurelien Aptel <aaptel@suse.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      caa2e7c7
    • Tetsuo Handa's avatar
      tty: vt: always invoke vc->vc_sw->con_resize callback · 2f2657e3
      Tetsuo Handa authored
      stable inclusion
      from linux-4.19.192
      commit 17d6c58c5fc522561daa4d3fb270edba933ac0a6
      
      --------------------------------
      
      commit ffb324e6f874121f7dce5bdae5e05d02baae7269 upstream.
      
      syzbot is reporting OOB write at vga16fb_imageblit() [1], for
      resize_screen() from ioctl(VT_RESIZE) returns 0 without checking whether
      requested rows/columns fit the amount of memory reserved for the graphical
      screen if current mode is KD_GRAPHICS.
      
      ----------
        #include <sys/types.h>
        #include <sys/stat.h>
        #include <fcntl.h>
        #include <sys/ioctl.h>
        #include <linux/kd.h>
        #include <linux/vt.h>
      
        int main(int argc, char *argv[])
        {
              const int fd = open("/dev/char/4:1", O_RDWR);
              struct vt_sizes vt = { 0x4100, 2 };
      
              ioctl(fd, KDSETMODE, KD_GRAPHICS);
              ioctl(fd, VT_RESIZE, &vt);
              ioctl(fd, KDSETMODE, KD_TEXT);
              return 0;
        }
      ----------
      
      Allow framebuffer drivers to return -EINVAL, by moving vc->vc_mode !=
      KD_GRAPHICS check from resize_screen() to fbcon_resize().
      
      Link: https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3
      
       [1]
      Reported-by: default avatarsyzbot <syzbot+1f29e126cf461c4de3b3@syzkaller.appspotmail.com>
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Tested-by: default avatarsyzbot <syzbot+1f29e126cf461c4de3b3@syzkaller.appspotmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      2f2657e3
    • Maciej W. Rozycki's avatar
      vt: Fix character height handling with VT_RESIZEX · cb173fc2
      Maciej W. Rozycki authored
      stable inclusion
      from linux-4.19.192
      commit 8c5ec4a731e1e2d9b6906bcde62de57a609a9b86
      
      --------------------------------
      
      commit 860dafa902595fb5f1d23bbcce1215188c3341e6 upstream.
      
      Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter
      which is the number of pixel rows per character (cell) rather than the
      height of the font used.
      
      For framebuffer devices the two values are always the same, because the
      former is inferred from the latter one.  For VGA used as a true text
      mode device these two parameters are independent from each other: the
      number of pixel rows per character is set in the CRT controller, while
      font height is in fact hardwired to 32 pixel rows and fonts of heights
      below that value are handled by padding their data with blanks when
      loaded to hardware for use by the character generator.  One can change
      the setting in the CRT controller and it will update the screen contents
      accordingly regardless of the font loaded.
      
      The `v_clin' parameter is used by the `vgacon' driver to set the height
      of the character cell and then the cursor position within.  Make the
      parameter explicit then, by defining a new `vc_cell_height' struct
      member of `vc_data', set it instead of `vc_font.height' from `v_clin' in
      the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver
      except where actual font data is accessed which as noted above is
      independent from the CRTC setting.
      
      This way the framebuffer console driver is free to ignore the `v_clin'
      parameter as irrelevant, as it always should have, avoiding any issues
      attempts to give the parameter a meaning there could have caused, such
      as one that has led to commit 988d0763 ("vt_ioctl: make VT_RESIZEX
      behave like VT_RESIZE"):
      
       "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2],
        for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height
        larger than actual font height calculated by con_font_set() from
        ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates
        minimal amount of memory based on actual font height calculated by
        con_font_set(), use of vt_resizex() can cause UAF/OOB read for font
        data."
      
      The problem first appeared around Linux 2.5.66 which predates our repo
      history, but the origin could be identified with the old MIPS/Linux repo
      also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git>
      as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX
      code in `vt_ioctl' was updated as follows:
      
       		if (clin)
      -			video_font_height = clin;
      +			vc->vc_font.height = clin;
      
      making the parameter apply to framebuffer devices as well, perhaps due
      to the use of "font" in the name of the original `video_font_height'
      variable.  Use "cell" in the new struct member then to avoid ambiguity.
      
      References:
      
      [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837
      [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3
      
      
      
      Signed-off-by: default avatarMaciej W. Rozycki <macro@orcam.me.uk>
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable@vger.kernel.org # v2.6.12+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      cb173fc2
    • Maciej W. Rozycki's avatar
      vgacon: Record video mode changes with VT_RESIZEX · 94284bd8
      Maciej W. Rozycki authored
      
      stable inclusion
      from linux-4.19.192
      commit 9a71ed8da907c36de4e96a8d78216231c0fe8df5
      
      --------------------------------
      
      commit d4d0ad57b3865795c4cde2fb5094c594c2e8f469 upstream.
      
      Fix an issue with VGA console font size changes made after the initial
      video text mode has been changed with a user tool like `svgatextmode'
      calling the VT_RESIZEX ioctl.  As it stands in that case the original
      screen geometry continues being used to validate further VT resizing.
      
      Consequently when the video adapter is firstly reprogrammed from the
      original say 80x25 text mode using a 9x16 character cell (720x400 pixel
      resolution) to say 80x37 text mode and the same character cell (720x592
      pixel resolution), and secondly the CRTC character cell updated to 9x8
      (by loading a suitable font with the KD_FONT_OP_SET request of the
      KDFONTOP ioctl), the VT geometry does not get further updated from 80x37
      and only upper half of the screen is used for the VT, with the lower
      half showing rubbish corresponding to whatever happens to be there in
      the video memory that maps to that part of the screen.  Of course the
      proportions change according to text mode geometries and font sizes
      chosen.
      
      Address the problem then, by updating the text mode geometry defaults
      rather than checking against them whenever the VT is resized via a user
      ioctl.
      
      Signed-off-by: default avatarMaciej W. Rozycki <macro@orcam.me.uk>
      Fixes: e400b6ec ("vt/vgacon: Check if screen resize request comes from userspace")
      Cc: stable@vger.kernel.org # v2.6.24+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      94284bd8
    • Greg Kroah-Hartman's avatar
      Revert "niu: fix missing checks of niu_pci_eeprom_read" · 5908c130
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit 8432db9d8a34f26030cee45e64a56a2e033d3ba6
      
      --------------------------------
      
      commit 7930742d6a0ff091c85b92ef4e076432d8d8cb79 upstream.
      
      This reverts commit 26fd962b.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      The change here was incorrect.  While it is nice to check if
      niu_pci_eeprom_read() succeeded or not when using the data, any error
      that might have happened was not propagated upwards properly, causing
      the kernel to assume that these reads were successful, which results in
      invalid data in the buffer that was to contain the successfully read
      data.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: Shannon Nelson <shannon.lee.nelson@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Fixes: 26fd962b ("niu: fix missing checks of niu_pci_eeprom_read")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-23-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      5908c130
    • Greg Kroah-Hartman's avatar
      Revert "qlcnic: Avoid potential NULL pointer dereference" · 214168de
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit 4190fc7c261cc0431483f44adedcce87320a6b8e
      
      --------------------------------
      
      commit b95b57dfe7a142bf2446548eb7f49340fd73e78b upstream.
      
      This reverts commit 5bf7295f.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      This commit does not properly detect if an error happens because the
      logic after this loop will not detect that there was a failed
      allocation.
      
      Cc: Aditya Pakki <pakki001@umn.edu>
      Cc: David S. Miller <davem@davemloft.net>
      Fixes: 5bf7295f ("qlcnic: Avoid potential NULL pointer dereference")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-25-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      214168de
    • Greg Kroah-Hartman's avatar
      Revert "rtlwifi: fix a potential NULL pointer dereference" · 9a8a6d14
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit ff867789b504162c982b99d463b77d4320fe478d
      
      --------------------------------
      
      commit 68c5634c4a7278672a3bed00eb5646884257c413 upstream.
      
      This reverts commit 76597628.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      This commit is not correct, it should not have used unlikely() and is
      not propagating the error properly to the calling function, so it should
      be reverted at this point in time.  Also, if the check failed, the
      work queue was still assumed to be allocated, so further accesses would
      have continued to fail, meaning this patch does nothing to solve the
      root issues at all.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: Bryan Brattlof <hello@bryanbrattlof.com>
      Fixes: 76597628 ("rtlwifi: fix a potential NULL pointer dereference")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-13-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      9a8a6d14
    • Greg Kroah-Hartman's avatar
      Revert "media: rcar_drif: fix a memory disclosure" · 71413de1
      Greg Kroah-Hartman authored
      
      stable inclusion
      from linux-4.19.192
      commit 4d08695b76ba20eff037ccb32cf3945f46498185
      
      --------------------------------
      
      commit 3e465fc3846734e9489273d889f19cc17b4cf4bd upstream.
      
      This reverts commit d3908323.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, it was determined that this commit is not needed at all as
      the media core already prevents memory disclosure on this codepath, so
      just drop the extra memset happening here.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Fixes: d3908323 ("media: rcar_drif: fix a memory disclosure")
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Reviewed-by: default avatarFabrizio Castro <fabrizio.castro.jz@renesas.com>
      Link: https://lore.kernel.org/r/20210503115736.2104747-4-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      71413de1
    • Greg Kroah-Hartman's avatar
      Revert "gdrom: fix a memory leak bug" · fdd33cc8
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit 69d17230341a313091ad10713acd2aa33acfc3b7
      
      --------------------------------
      
      commit 257343d3ed557f11d580d0b7c515dc154f64a42b upstream.
      
      This reverts commit 093c4821.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      Because of this, all submissions from this group must be reverted from
      the kernel tree and will need to be re-reviewed again to determine if
      they actually are a valid fix.  Until that work is complete, remove this
      change to ensure that no problems are being introduced into the
      codebase.
      
      Cc: Wenwen Wang <wang6495@umn.edu>
      Cc: Peter Rosin <peda@axentia.se>
      Cc: Jens Axboe <axboe@kernel.dk>
      Fixes: 093c4821 ("gdrom: fix a memory leak bug")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-27-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      fdd33cc8
    • Greg Kroah-Hartman's avatar
      Revert "scsi: ufs: fix a missing check of devm_reset_control_get" · 0037259c
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit 12b6934b22083a9ab30db104d81c49e43a5ab1c8
      
      --------------------------------
      
      commit 4d427b408c4c2ff1676966c72119a3a559f8e39b upstream.
      
      This reverts commit 63a06181.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      The original commit is incorrect, it does not properly clean up on the
      error path, so I'll keep the revert and fix it up properly with a
      follow-on patch.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: Avri Altman <avri.altman@wdc.com>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Fixes: 63a06181 ("scsi: ufs: fix a missing check of devm_reset_control_get")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-31-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      0037259c
    • Greg Kroah-Hartman's avatar
      Revert "video: imsttfb: fix potential NULL pointer dereferences" · 89d6ade2
      Greg Kroah-Hartman authored
      
      stable inclusion
      from linux-4.19.192
      commit 94deabc3da468888b9abd8d7f4df3e7d1a43e497
      
      --------------------------------
      
      commit ed04fe8a0e87d7b5ea17d47f4ac9ec962b24814a upstream.
      
      This reverts commit 1d84353d.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      The original commit here, while technically correct, did not fully
      handle all of the reported issues that the commit stated it was fixing,
      so revert it until it can be "fixed" fully.
      
      Note, ioremap() probably will never fail for old hardware like this, and
      if anyone actually used this hardware (a PowerMac era PCI display card),
      they would not be using fbdev anymore.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: Aditya Pakki <pakki001@umn.edu>
      Cc: Finn Thain <fthain@telegraphics.com.au>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Fixes: 1d84353d ("video: imsttfb: fix potential NULL pointer dereferences")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-67-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      89d6ade2
    • Greg Kroah-Hartman's avatar
      Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe" · a82316a7
      Greg Kroah-Hartman authored
      
      stable inclusion
      from linux-4.19.192
      commit ec19a4fba56a0ca3143f2ac192764f769f88453a
      
      --------------------------------
      
      commit 99ae3417672a6d4a3bf68d4fc43d7c6ca074d477 upstream.
      
      This reverts commit 9aa3aa15.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, it was determined that this commit is not needed at all so
      just revert it.  Also, the call to lm80_init_client() was not properly
      handled, so if error handling is needed in the lm80_probe() function,
      then it should be done properly, not half-baked like the commit being
      reverted here did.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Fixes: 9aa3aa15 ("hwmon: (lm80) fix a missing check of bus read in lm80 probe")
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20210503115736.2104747-5-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      a82316a7
    • Greg Kroah-Hartman's avatar
      Revert "leds: lp5523: fix a missing check of return value of lp55xx_read" · 5c6e86bf
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit f7bce372a9e415990c6b9852febc7fb0ffc93729
      
      --------------------------------
      
      commit 8d1beda5f11953ffe135a5213287f0b25b4da41b upstream.
      
      This reverts commit 248b5701.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      The original commit does not properly unwind if there is an error
      condition so it needs to be reverted at this point in time.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Fixes: 248b5701 ("leds: lp5523: fix a missing check of return value of lp55xx_read")
      Link: https://lore.kernel.org/r/20210503115736.2104747-9-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      5c6e86bf
    • Greg Kroah-Hartman's avatar
      Revert "net: stmicro: fix a missing check of clk_prepare" · d3ec275f
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit 84a7ffe7a4a3a742180109e273d2e400ed0c1ace
      
      --------------------------------
      
      commit bee1b0511844c8c79fccf1f2b13472393b6b91f7 upstream.
      
      This reverts commit f86a3b83.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      The original commit causes a memory leak when it is trying to claim it
      is properly handling errors.  Revert this change and fix it up properly
      in a follow-on commit.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: David S. Miller <davem@davemloft.net>
      Fixes: f86a3b83 ("net: stmicro: fix a missing check of clk_prepare")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-21-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      d3ec275f
    • Greg Kroah-Hartman's avatar
      Revert "video: hgafb: fix potential NULL pointer dereference" · 442f6030
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit 84c19f6a5cbb0c4bc96fbb7b29acdba918e94992
      
      --------------------------------
      
      commit 58c0cc2d90f1e37c4eb63ae7f164c83830833f78 upstream.
      
      This reverts commit ec7f6aad.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      This patch "looks" correct, but the driver keeps on running and will
      fail horribly right afterward if this error condition ever trips.
      
      So points for trying to resolve an issue, but a huge NEGATIVE value for
      providing a "fake" fix for the problem as nothing actually got resolved
      at all.  I'll go fix this up properly...
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: Aditya Pakki <pakki001@umn.edu>
      Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Fixes: ec7f6aad ("video: hgafb: fix potential NULL pointer dereference")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-39-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      442f6030
    • Mikulas Patocka's avatar
      dm snapshot: fix crash with transient storage and zero chunk size · 6a7fb7dd
      Mikulas Patocka authored
      
      stable inclusion
      from linux-4.19.192
      commit 1ff004c41c8205d7677f7b9d7da238a5d9a29274
      
      --------------------------------
      
      commit c699a0db2d62e3bbb7f0bf35c87edbc8d23e3062 upstream.
      
      The following commands will crash the kernel:
      
      modprobe brd rd_size=1048576
      dmsetup create o --table "0 `blockdev --getsize /dev/ram0` snapshot-origin /dev/ram0"
      dmsetup create s --table "0 `blockdev --getsize /dev/ram0` snapshot /dev/ram0 /dev/ram1 N 0"
      
      The reason is that when we test for zero chunk size, we jump to the label
      bad_read_metadata without setting the "r" variable. The function
      snapshot_ctr destroys all the structures and then exits with "r == 0". The
      kernel then crashes because it falsely believes that snapshot_ctr
      succeeded.
      
      In order to fix the bug, we set the variable "r" to -EINVAL.
      
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      6a7fb7dd
    • Greg Kroah-Hartman's avatar
      Revert "serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference" · 431710ee
      Greg Kroah-Hartman authored
      
      stable inclusion
      from linux-4.19.192
      commit c5fc7a18c0616f468b30430ce34498d51481bfac
      
      --------------------------------
      
      commit 754f39158441f4c0d7a8255209dd9a939f08ce80 upstream.
      
      This reverts commit 32f47179.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be not be needed at all as the
      change was useless because this function can only be called when
      of_match_device matched on something.  So it should be reverted.
      
      Cc: Aditya Pakki <pakki001@umn.edu>
      Cc: stable <stable@vger.kernel.org>
      Fixes: 32f47179 ("serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference")
      Acked-by: default avatarJiri Slaby <jirislaby@kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-6-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      431710ee
    • Greg Kroah-Hartman's avatar
      Revert "rapidio: fix a NULL pointer dereference when create_workqueue() fails" · 1d2c62ae
      Greg Kroah-Hartman authored
      stable inclusion
      from linux-4.19.192
      commit 15d3547758b369db1690adda381a360a0e821bed
      
      --------------------------------
      
      commit 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb upstream.
      
      This reverts commit 23015b22.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      The original commit has a memory leak on the error path here, it does
      not clean up everything properly.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Cc: Alexandre Bounine <alex.bou9@gmail.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Fixes: 23015b22 ("rapidio: fix a NULL pointer dereference when create_workqueue() fails")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-45-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      1d2c62ae
    • Greg Kroah-Hartman's avatar
      Revert "ALSA: sb8: add a check for request_region" · 6fd29a94
      Greg Kroah-Hartman authored
      
      stable inclusion
      from linux-4.19.192
      commit 14b3bb3da626129da01f6db48e13b9220b7913ed
      
      --------------------------------
      
      commit 94f88309f201821073f57ae6005caefa61bf7b7e upstream.
      
      This reverts commit dcd0feac.
      
      Because of recent interactions with developers from @umn.edu, all
      commits from them have been recently re-reviewed to ensure if they were
      correct or not.
      
      Upon review, this commit was found to be incorrect for the reasons
      below, so it must be reverted.  It will be fixed up "correctly" in a
      later kernel change.
      
      The original commit message for this change was incorrect as the code
      path can never result in a NULL dereference, alluding to the fact that
      whatever tool was used to "find this" is broken.  It's just an optional
      resource reservation, so removing this check is fine.
      
      Cc: Kangjie Lu <kjlu@umn.edu>
      Acked-by: default avatarTakashi Iwai <tiwai@suse.de>
      Fixes: dcd0feac ("ALSA: sb8: add a check for request_region")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210503115736.2104747-35-gregkh@linuxfoundation.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      6fd29a94
    • Ronnie Sahlberg's avatar
      cifs: fix memory leak in smb2_copychunk_range · cb98f3a7
      Ronnie Sahlberg authored
      
      stable inclusion
      from linux-4.19.192
      commit 4e95d8160aa7eaaa185b8c1d16294d9e79444aeb
      
      --------------------------------
      
      commit d201d7631ca170b038e7f8921120d05eec70d7c5 upstream.
      
      When using smb2_copychunk_range() for large ranges we will
      run through several iterations of a loop calling SMB2_ioctl()
      but never actually free the returned buffer except for the final
      iteration.
      This leads to memory leaks everytime a large copychunk is requested.
      
      Fixes: 9bf0c9cd ("CIFS: Fix SMB2/SMB3 Copy offload support (refcopy) for large files")
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      cb98f3a7
    • Zqiang's avatar
      locking/mutex: clear MUTEX_FLAGS if wait_list is empty due to signal · d121a8d8
      Zqiang authored
      
      stable inclusion
      from linux-4.19.192
      commit b31395e0d19017aaa83ee0e2dc0862954aca3aa3
      
      --------------------------------
      
      [ Upstream commit 3a010c493271f04578b133de977e0e5dd2848cea ]
      
      When a interruptible mutex locker is interrupted by a signal
      without acquiring this lock and removed from the wait queue.
      if the mutex isn't contended enough to have a waiter
      put into the wait queue again, the setting of the WAITER
      bit will force mutex locker to go into the slowpath to
      acquire the lock every time, so if the wait queue is empty,
      the WAITER bit need to be clear.
      
      Fixes: 040a0a37 ("mutex: Add support for wound/wait style locks")
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarZqiang <qiang.zhang@windriver.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20210517034005.30828-1-qiang.zhang@windriver.com
      
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      d121a8d8
    • Daniel Wagner's avatar
      nvmet: seset ns->file when open fails · 88a07cc4
      Daniel Wagner authored
      
      stable inclusion
      from linux-4.19.192
      commit 6671cd54fd21fe8c31fa5c4b28d3c7e96945cd35
      
      --------------------------------
      
      [ Upstream commit 85428beac80dbcace5b146b218697c73e367dcf5 ]
      
      Reset the ns->file value to NULL also in the error case in
      nvmet_file_ns_enable().
      
      The ns->file variable points either to file object or contains the
      error code after the filp_open() call. This can lead to following
      problem:
      
      When the user first setups an invalid file backend and tries to enable
      the ns, it will fail. Then the user switches over to a bdev backend
      and enables successfully the ns. The first received I/O will crash the
      system because the IO backend is chosen based on the ns->file value:
      
      static u16 nvmet_parse_io_cmd(struct nvmet_req *req)
      {
      	[...]
      
      	if (req->ns->file)
      		return nvmet_file_parse_io_cmd(req);
      
      	return nvmet_bdev_parse_io_cmd(req);
      }
      
      Reported-by: default avatarEnzo Matsumiya <ematsumiya@suse.com>
      Signed-off-by: default avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      88a07cc4
    • Oleg Nesterov's avatar
      ptrace: make ptrace() fail if the tracee changed its pid unexpectedly · 6a2dfc92
      Oleg Nesterov authored
      
      stable inclusion
      from linux-4.19.192
      commit 365e5534cf89cff7def13f94b18f26ae4670e0cd
      
      --------------------------------
      
      [ Upstream commit dbb5afad100a828c97e012c6106566d99f041db6 ]
      
      Suppose we have 2 threads, the group-leader L and a sub-theread T,
      both parked in ptrace_stop(). Debugger tries to resume both threads
      and does
      
      	ptrace(PTRACE_CONT, T);
      	ptrace(PTRACE_CONT, L);
      
      If the sub-thread T execs in between, the 2nd PTRACE_CONT doesn not
      resume the old leader L, it resumes the post-exec thread T which was
      actually now stopped in PTHREAD_EVENT_EXEC. In this case the
      PTHREAD_EVENT_EXEC event is lost, and the tracer can't know that the
      tracee changed its pid.
      
      This patch makes ptrace() fail in this case until debugger does wait()
      and consumes PTHREAD_EVENT_EXEC which reports old_pid. This affects all
      ptrace requests except the "asynchronous" PTRACE_INTERRUPT/KILL.
      
      The patch doesn't add the new PTRACE_ option to not complicate the API,
      and I _hope_ this won't cause any noticeable regression:
      
      	- If debugger uses PTRACE_O_TRACEEXEC and the thread did an exec
      	  and the tracer does a ptrace request without having consumed
      	  the exec event, it's 100% sure that the thread the ptracer
      	  thinks it is targeting does not exist anymore, or isn't the
      	  same as the one it thinks it is targeting.
      
      	- To some degree this patch adds nothing new. In the scenario
      	  above ptrace(L) can fail with -ESRCH if it is called after the
      	  execing sub-thread wakes the leader up and before it "steals"
      	  the leader's pid.
      
      Test-case:
      
      	#include <stdio.h>
      	#include <unistd.h>
      	#include <signal.h>
      	#include <sys/ptrace.h>
      	#include <sys/wait.h>
      	#include <errno.h>
      	#include <pthread.h>
      	#include <assert.h>
      
      	void *tf(void *arg)
      	{
      		execve("/usr/bin/true", NULL, NULL);
      		assert(0);
      
      		return NULL;
      	}
      
      	int main(void)
      	{
      		int leader = fork();
      		if (!leader) {
      			kill(getpid(), SIGSTOP);
      
      			pthread_t th;
      			pthread_create(&th, NULL, tf, NULL);
      			for (;;)
      				pause();
      
      			return 0;
      		}
      
      		waitpid(leader, NULL, WSTOPPED);
      
      		ptrace(PTRACE_SEIZE, leader, 0,
      				PTRACE_O_TRACECLONE | PTRACE_O_TRACEEXEC);
      		waitpid(leader, NULL, 0);
      
      		ptrace(PTRACE_CONT, leader, 0,0);
      		waitpid(leader, NULL, 0);
      
      		int status, thread = waitpid(-1, &status, 0);
      		assert(thread > 0 && thread != leader);
      		assert(status == 0x80137f);
      
      		ptrace(PTRACE_CONT, thread, 0,0);
      		/*
      		 * waitid() because waitpid(leader, &status, WNOWAIT) does not
      		 * report status. Why ????
      		 *
      		 * Why WEXITED? because we have another kernel problem connected
      		 * to mt-exec.
      		 */
      		siginfo_t info;
      		assert(waitid(P_PID, leader, &info, WSTOPPED|WEXITED|WNOWAIT) == 0);
      		assert(info.si_pid == leader && info.si_status == 0x0405);
      
      		/* OK, it sleeps in ptrace(PTRACE_EVENT_EXEC == 0x04) */
      		assert(ptrace(PTRACE_CONT, leader, 0,0) == -1);
      		assert(errno == ESRCH);
      
      		assert(leader == waitpid(leader, &status, WNOHANG));
      		assert(status == 0x04057f);
      
      		assert(ptrace(PTRACE_CONT, leader, 0,0) == 0);
      
      		return 0;
      	}
      
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: default avatarSimon Marchi <simon.marchi@efficios.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarPedro Alves <palves@redhat.com>
      Acked-by: default avatarSimon Marchi <simon.marchi@efficios.com>
      Acked-by: default avatarJan Kratochvil <jan.kratochvil@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      6a2dfc92
    • Dan Carpenter's avatar
      firmware: arm_scpi: Prevent the ternary sign expansion bug · 8351cce4
      Dan Carpenter authored
      stable inclusion
      from linux-4.19.192
      commit dcbce0b6f38476b380a0dec28e237d9398ca2bfe
      
      --------------------------------
      
      [ Upstream commit d9cd78edb2e6b7e26747c0ec312be31e7ef196fe ]
      
      How the type promotion works in ternary expressions is a bit tricky.
      The problem is that scpi_clk_get_val() returns longs, "ret" is a int
      which holds a negative error code, and le32_to_cpu() is an unsigned int.
      We want the negative error code to be cast to a negative long.  But
      because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and
      becomes a high positive and then it is promoted to long and it is still
      a high positive value.
      
      Fix this by getting rid of the ternary.
      
      Link: https://lore.kernel.org/r/YIE7pdqV/h10tEAK@mwanda
      
      
      Fixes: 8cb7cf56 ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol")
      Reviewed-by: default avatarCristian Marussi <cristian.marussi@arm.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      [sudeep.holla: changed to return 0 as clock rate on error]
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      8351cce4
    • Eric Dumazet's avatar
      ipv6: remove extra dev_hold() for fallback tunnels · 190c77ea
      Eric Dumazet authored
      
      stable inclusion
      from linux-4.19.191
      commit 867fd8d5613e0632712bdc15167d8ce9eb2c0f8b
      
      --------------------------------
      
      commit 0d7a7b2014b1a499a0fe24c9f3063d7856b5aaaf upstream.
      
      My previous commits added a dev_hold() in tunnels ndo_init(),
      but forgot to remove it from special functions setting up fallback tunnels.
      
      Fallback tunnels do call their respective ndo_init()
      
      This leads to various reports like :
      
      unregister_netdevice: waiting for ip6gre0 to become free. Usage count = 2
      
      Fixes: 48bb5697269a ("ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods")
      Fixes: 6289a98f0817 ("sit: proper dev_{hold|put} in ndo_[un]init methods")
      Fixes: 40cb881b5aaa ("ip6_vti: proper dev_{hold|put} in ndo_[un]init methods")
      Fixes: 7f700334be9a ("ip6_gre: proper dev_{hold|put} in ndo_[un]init methods")
      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>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      190c77ea
    • Eric Dumazet's avatar
      ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods · e51577d3
      Eric Dumazet authored
      
      stable inclusion
      from linux-4.19.191
      commit 873d5de7f7477a5c7258a9dc3967053f466257a2
      
      --------------------------------
      
      commit 48bb5697269a7cbe5194dbb044dc38c517e34c58 upstream.
      
      Same reasons than for the previous commits :
      6289a98f0817 ("sit: proper dev_{hold|put} in ndo_[un]init methods")
      40cb881b5aaa ("ip6_vti: proper dev_{hold|put} in ndo_[un]init methods")
      7f700334be9a ("ip6_gre: proper dev_{hold|put} in ndo_[un]init methods")
      
      After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger
      a warning [1]
      
      Issue here is that:
      
      - all dev_put() should be paired with a corresponding prior dev_hold().
      
      - A driver doing a dev_put() in its ndo_uninit() MUST also
        do a dev_hold() in its ndo_init(), only when ndo_init()
        is returning 0.
      
      Otherwise, register_netdevice() would call ndo_uninit()
      in its error path and release a refcount too soon.
      
      [1]
      WARNING: CPU: 1 PID: 21059 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
      Modules linked in:
      CPU: 1 PID: 21059 Comm: syz-executor.4 Not tainted 5.12.0-rc4-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
      Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58
      RSP: 0018:ffffc900025aefe8 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000040000 RSI: ffffffff815c51f5 RDI: fffff520004b5def
      RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff888023488568
      R13: ffff8880254e9000 R14: 00000000dfd82cfd R15: ffff88802ee2d7c0
      FS:  00007f13bc590700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f0943e74000 CR3: 0000000025273000 CR4: 00000000001506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       __refcount_dec include/linux/refcount.h:344 [inline]
       refcount_dec include/linux/refcount.h:359 [inline]
       dev_put include/linux/netdevice.h:4135 [inline]
       ip6_tnl_dev_uninit+0x370/0x3d0 net/ipv6/ip6_tunnel.c:387
       register_netdevice+0xadf/0x1500 net/core/dev.c:10308
       ip6_tnl_create2+0x1b5/0x400 net/ipv6/ip6_tunnel.c:263
       ip6_tnl_newlink+0x312/0x580 net/ipv6/ip6_tunnel.c:2052
       __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443
       rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491
       rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553
       netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
       netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
       netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
       netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
       sock_sendmsg_nosec net/socket.c:654 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:674
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Fixes: 919067cc845f ("net: add CONFIG_PCPU_DEV_REFCNT")
      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>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      e51577d3
    • Eric Dumazet's avatar
      sit: proper dev_{hold|put} in ndo_[un]init methods · 49580735
      Eric Dumazet authored
      
      stable inclusion
      from linux-4.19.191
      commit 01cc9ab6fdf1ddb0a5355196557b95819788f9bb
      
      --------------------------------
      
      commit 6289a98f0817a4a457750d6345e754838eae9439 upstream.
      
      After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger
      a warning [1]
      
      Issue here is that:
      
      - all dev_put() should be paired with a corresponding prior dev_hold().
      
      - A driver doing a dev_put() in its ndo_uninit() MUST also
        do a dev_hold() in its ndo_init(), only when ndo_init()
        is returning 0.
      
      Otherwise, register_netdevice() would call ndo_uninit()
      in its error path and release a refcount too soon.
      
      Fixes: 919067cc845f ("net: add CONFIG_PCPU_DEV_REFCNT")
      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>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      49580735
    • Eric Dumazet's avatar
      ip6_gre: proper dev_{hold|put} in ndo_[un]init methods · 1676a202
      Eric Dumazet authored
      
      stable inclusion
      from linux-4.19.191
      commit 2dc72d6a7f0e8b2eff9f17959157cf50618bc1ca
      
      --------------------------------
      
      commit 7f700334be9aeb91d5d86ef9ad2d901b9b453e9b upstream.
      
      After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger
      a warning [1]
      
      Issue here is that:
      
      - all dev_put() should be paired with a corresponding dev_hold(),
        and vice versa.
      
      - A driver doing a dev_put() in its ndo_uninit() MUST also
        do a dev_hold() in its ndo_init(), only when ndo_init()
        is returning 0.
      
      Otherwise, register_netdevice() would call ndo_uninit()
      in its error path and release a refcount too soon.
      
      ip6_gre for example (among others problematic drivers)
      has to use dev_hold() in ip6gre_tunnel_init_common()
      instead of from ip6gre_newlink_common(), covering
      both ip6gre_tunnel_init() and ip6gre_tap_init()/
      
      Note that ip6gre_tunnel_init_common() is not called from
      ip6erspan_tap_init() thus we also need to add a dev_hold() there,
      as ip6erspan_tunnel_uninit() does call dev_put()
      
      [1]
      refcount_t: decrement hit 0; leaking memory.
      WARNING: CPU: 0 PID: 8422 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
      Modules linked in:
      CPU: 1 PID: 8422 Comm: syz-executor854 Not tainted 5.12.0-rc4-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
      Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58
      RSP: 0018:ffffc900018befd0 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: ffff88801ef19c40 RSI: ffffffff815c51f5 RDI: fffff52000317dec
      RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff888018cf4568
      R13: ffff888018cf4c00 R14: ffff8880228f2000 R15: ffffffff8d659b80
      FS:  00000000014eb300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055d7bf2b3138 CR3: 0000000014933000 CR4: 00000000001506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       __refcount_dec include/linux/refcount.h:344 [inline]
       refcount_dec include/linux/refcount.h:359 [inline]
       dev_put include/linux/netdevice.h:4135 [inline]
       ip6gre_tunnel_uninit+0x3d7/0x440 net/ipv6/ip6_gre.c:420
       register_netdevice+0xadf/0x1500 net/core/dev.c:10308
       ip6gre_newlink_common.constprop.0+0x158/0x410 net/ipv6/ip6_gre.c:1984
       ip6gre_newlink+0x275/0x7a0 net/ipv6/ip6_gre.c:2017
       __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443
       rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491
       rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553
       netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
       netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
       netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
       netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
       sock_sendmsg_nosec net/socket.c:654 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:674
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
      
      Fixes: 919067cc845f ("net: add CONFIG_PCPU_DEV_REFCNT")
      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>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      1676a202
    • yangerkun's avatar
      block: reexpand iov_iter after read/write · 02fe1bf1
      yangerkun authored
      
      stable inclusion
      from linux-4.19.191
      commit b9bcbc3c743c46bead89dffe4283ff7cd9e118bf
      
      --------------------------------
      
      [ Upstream commit cf7b39a0cbf6bf57aa07a008d46cf695add05b4c ]
      
      We get a bug:
      
      BUG: KASAN: slab-out-of-bounds in iov_iter_revert+0x11c/0x404
      lib/iov_iter.c:1139
      Read of size 8 at addr ffff0000d3fb11f8 by task
      
      CPU: 0 PID: 12582 Comm: syz-executor.2 Not tainted
      5.10.0-00843-g352c8610ccd2 #2
      Hardware name: linux,dummy-virt (DT)
      Call trace:
       dump_backtrace+0x0/0x2d0 arch/arm64/kernel/stacktrace.c:132
       show_stack+0x28/0x34 arch/arm64/kernel/stacktrace.c:196
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x110/0x164 lib/dump_stack.c:118
       print_address_description+0x78/0x5c8 mm/kasan/report.c:385
       __kasan_report mm/kasan/report.c:545 [inline]
       kasan_report+0x148/0x1e4 mm/kasan/report.c:562
       check_memory_region_inline mm/kasan/generic.c:183 [inline]
       __asan_load8+0xb4/0xbc mm/kasan/generic.c:252
       iov_iter_revert+0x11c/0x404 lib/iov_iter.c:1139
       io_read fs/io_uring.c:3421 [inline]
       io_issue_sqe+0x2344/0x2d64 fs/io_uring.c:5943
       __io_queue_sqe+0x19c/0x520 fs/io_uring.c:6260
       io_queue_sqe+0x2a4/0x590 fs/io_uring.c:6326
       io_submit_sqe fs/io_uring.c:6395 [inline]
       io_submit_sqes+0x4c0/0xa04 fs/io_uring.c:6624
       __do_sys_io_uring_enter fs/io_uring.c:9013 [inline]
       __se_sys_io_uring_enter fs/io_uring.c:8960 [inline]
       __arm64_sys_io_uring_enter+0x190/0x708 fs/io_uring.c:8960
       __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
       invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
       el0_svc_common arch/arm64/kernel/syscall.c:158 [inline]
       do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:227
       el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367
       el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383
       el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670
      
      Allocated by task 12570:
       stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121
       kasan_save_stack mm/kasan/common.c:48 [inline]
       kasan_set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc+0xdc/0x120 mm/kasan/common.c:461
       kasan_kmalloc+0xc/0x14 mm/kasan/common.c:475
       __kmalloc+0x23c/0x334 mm/slub.c:3970
       kmalloc include/linux/slab.h:557 [inline]
       __io_alloc_async_data+0x68/0x9c fs/io_uring.c:3210
       io_setup_async_rw fs/io_uring.c:3229 [inline]
       io_read fs/io_uring.c:3436 [inline]
       io_issue_sqe+0x2954/0x2d64 fs/io_uring.c:5943
       __io_queue_sqe+0x19c/0x520 fs/io_uring.c:6260
       io_queue_sqe+0x2a4/0x590 fs/io_uring.c:6326
       io_submit_sqe fs/io_uring.c:6395 [inline]
       io_submit_sqes+0x4c0/0xa04 fs/io_uring.c:6624
       __do_sys_io_uring_enter fs/io_uring.c:9013 [inline]
       __se_sys_io_uring_enter fs/io_uring.c:8960 [inline]
       __arm64_sys_io_uring_enter+0x190/0x708 fs/io_uring.c:8960
       __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
       invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
       el0_svc_common arch/arm64/kernel/syscall.c:158 [inline]
       do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:227
       el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367
       el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383
       el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670
      
      Freed by task 12570:
       stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121
       kasan_save_stack mm/kasan/common.c:48 [inline]
       kasan_set_track+0x38/0x6c mm/kasan/common.c:56
       kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:355
       __kasan_slab_free+0x124/0x150 mm/kasan/common.c:422
       kasan_slab_free+0x10/0x1c mm/kasan/common.c:431
       slab_free_hook mm/slub.c:1544 [inline]
       slab_free_freelist_hook mm/slub.c:1577 [inline]
       slab_free mm/slub.c:3142 [inline]
       kfree+0x104/0x38c mm/slub.c:4124
       io_dismantle_req fs/io_uring.c:1855 [inline]
       __io_free_req+0x70/0x254 fs/io_uring.c:1867
       io_put_req_find_next fs/io_uring.c:2173 [inline]
       __io_queue_sqe+0x1fc/0x520 fs/io_uring.c:6279
       __io_req_task_submit+0x154/0x21c fs/io_uring.c:2051
       io_req_task_submit+0x2c/0x44 fs/io_uring.c:2063
       task_work_run+0xdc/0x128 kernel/task_work.c:151
       get_signal+0x6f8/0x980 kernel/signal.c:2562
       do_signal+0x108/0x3a4 arch/arm64/kernel/signal.c:658
       do_notify_resume+0xbc/0x25c arch/arm64/kernel/signal.c:722
       work_pending+0xc/0x180
      
      blkdev_read_iter can truncate iov_iter's count since the count + pos may
      exceed the size of the blkdev. This will confuse io_read that we have
      consume the iovec. And once we do the iov_iter_revert in io_read, we
      will trigger the slab-out-of-bounds. Fix it by reexpand the count with
      size has been truncated.
      
      blkdev_write_iter can trigger the problem too.
      
      Signed-off-by: default avataryangerkun <yangerkun@huawei.com>
      Acked-by: default avatarPavel Begunkov <asml.silencec@gmail.com>
      Link: https://lore.kernel.org/r/20210401071807.3328235-1-yangerkun@huawei.com
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      02fe1bf1
    • Bodo Stroesser's avatar
      scsi: target: tcmu: Return from tcmu_handle_completions() if cmd_id not found · ec0a2de0
      Bodo Stroesser authored
      stable inclusion
      from linux-4.19.191
      commit 84d29b2fb3caf42d0bb0907a0ba01fa111ff4791
      
      --------------------------------
      
      [ Upstream commit 9814b55cde0588b6d9bc496cee43f87316cbc6f1 ]
      
      If tcmu_handle_completions() finds an invalid cmd_id while looping over cmd
      responses from userspace it sets TCMU_DEV_BIT_BROKEN and breaks the
      loop. This means that it does further handling for the tcmu device.
      
      Skip that handling by replacing 'break' with 'return'.
      
      Additionally change tcmu_handle_completions() from unsigned int to bool,
      since the value used in return already is bool.
      
      Link: https://lore.kernel.org/r/20210423150123.24468-1-bostroesser@gmail.com
      
      
      Signed-off-by: default avatarBodo Stroesser <bostroesser@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      ec0a2de0