5.6-stable patches

added patches:
	ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch
	ovl-initialize-error-in-ovl_copy_xattr.patch
	proc-use-new_inode-not-new_inode_pseudo.patch
	remoteproc-fall-back-to-using-parent-memory-pool-if-no-dedicated-available.patch
	remoteproc-fix-and-restore-the-parenting-hierarchy-for-vdev.patch

diff --git a/queue-5.6/ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch b/queue-5.6/ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch
new file mode 100644 (file)
index 0000000..fdcc805
--- /dev/null
+++ b/queue-5.6/ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch
@@ -0,0 +1,43 @@
+From 522f6e6cba6880a038e2bd88e10390b84cd3febd Mon Sep 17 00:00:00 2001
+From: Amir Goldstein <amir73il@gmail.com>
+Date: Sat, 23 May 2020 16:21:55 +0300
+Subject: ovl: fix out of bounds access warning in ovl_check_fb_len()
+
+From: Amir Goldstein <amir73il@gmail.com>
+
+commit 522f6e6cba6880a038e2bd88e10390b84cd3febd upstream.
+
+syzbot reported out of bounds memory access from open_by_handle_at()
+with a crafted file handle that looks like this:
+
+  { .handle_bytes = 2, .handle_type = OVL_FILEID_V1 }
+
+handle_bytes gets rounded down to 0 and we end up calling:
+  ovl_check_fh_len(fh, 0) => ovl_check_fb_len(fh + 3, -3)
+
+But fh buffer is only 2 bytes long, so accessing struct ovl_fb at
+fh + 3 is illegal.
+
+Fixes: cbe7fba8edfc ("ovl: make sure that real fid is 32bit aligned in memory")
+Reported-and-tested-by: syzbot+61958888b1c60361a791@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org> # v5.5
+Signed-off-by: Amir Goldstein <amir73il@gmail.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/overlayfs/overlayfs.h |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/overlayfs/overlayfs.h
++++ b/fs/overlayfs/overlayfs.h
+@@ -339,6 +339,9 @@ int ovl_check_fb_len(struct ovl_fb *fb,
+ 
+ static inline int ovl_check_fh_len(struct ovl_fh *fh, int fh_len)
+ {
++      if (fh_len < sizeof(struct ovl_fh))
++              return -EINVAL;
++
+       return ovl_check_fb_len(&fh->fb, fh_len - OVL_FH_WIRE_OFFSET);
+ }
+ 

diff --git a/queue-5.6/ovl-initialize-error-in-ovl_copy_xattr.patch b/queue-5.6/ovl-initialize-error-in-ovl_copy_xattr.patch
new file mode 100644 (file)
index 0000000..9d9f6d2
--- /dev/null
+++ b/queue-5.6/ovl-initialize-error-in-ovl_copy_xattr.patch
@@ -0,0 +1,46 @@
+From 520da69d265a91c6536c63851cbb8a53946974f0 Mon Sep 17 00:00:00 2001
+From: Yuxuan Shui <yshuiv7@gmail.com>
+Date: Wed, 27 May 2020 04:08:02 +0100
+Subject: ovl: initialize error in ovl_copy_xattr
+
+From: Yuxuan Shui <yshuiv7@gmail.com>
+
+commit 520da69d265a91c6536c63851cbb8a53946974f0 upstream.
+
+In ovl_copy_xattr, if all the xattrs to be copied are overlayfs private
+xattrs, the copy loop will terminate without assigning anything to the
+error variable, thus returning an uninitialized value.
+
+If ovl_copy_xattr is called from ovl_clear_empty, this uninitialized error
+value is put into a pointer by ERR_PTR(), causing potential invalid memory
+accesses down the line.
+
+This commit initialize error with 0. This is the correct value because when
+there's no xattr to copy, because all xattrs are private, ovl_copy_xattr
+should succeed.
+
+This bug is discovered with the help of INIT_STACK_ALL and clang.
+
+Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
+Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1050405
+Fixes: 0956254a2d5b ("ovl: don't copy up opaqueness")
+Cc: stable@vger.kernel.org # v4.8
+Signed-off-by: Alexander Potapenko <glider@google.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/overlayfs/copy_up.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/overlayfs/copy_up.c
++++ b/fs/overlayfs/copy_up.c
+@@ -40,7 +40,7 @@ int ovl_copy_xattr(struct dentry *old, s
+ {
+       ssize_t list_size, size, value_size = 0;
+       char *buf, *name, *value = NULL;
+-      int uninitialized_var(error);
++      int error = 0;
+       size_t slen;
+ 
+       if (!(old->d_inode->i_opflags & IOP_XATTR) ||

diff --git a/queue-5.6/proc-use-new_inode-not-new_inode_pseudo.patch b/queue-5.6/proc-use-new_inode-not-new_inode_pseudo.patch
new file mode 100644 (file)
index 0000000..1f3c1a2
--- /dev/null
+++ b/queue-5.6/proc-use-new_inode-not-new_inode_pseudo.patch
@@ -0,0 +1,83 @@
+From ef1548adada51a2f32ed7faef50aa465e1b4c5da Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Fri, 12 Jun 2020 09:42:03 -0500
+Subject: proc: Use new_inode not new_inode_pseudo
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit ef1548adada51a2f32ed7faef50aa465e1b4c5da upstream.
+
+Recently syzbot reported that unmounting proc when there is an ongoing
+inotify watch on the root directory of proc could result in a use
+after free when the watch is removed after the unmount of proc
+when the watcher exits.
+
+Commit 69879c01a0c3 ("proc: Remove the now unnecessary internal mount
+of proc") made it easier to unmount proc and allowed syzbot to see the
+problem, but looking at the code it has been around for a long time.
+
+Looking at the code the fsnotify watch should have been removed by
+fsnotify_sb_delete in generic_shutdown_super.  Unfortunately the inode
+was allocated with new_inode_pseudo instead of new_inode so the inode
+was not on the sb->s_inodes list.  Which prevented
+fsnotify_unmount_inodes from finding the inode and removing the watch
+as well as made it so the "VFS: Busy inodes after unmount" warning
+could not find the inodes to warn about them.
+
+Make all of the inodes in proc visible to generic_shutdown_super,
+and fsnotify_sb_delete by using new_inode instead of new_inode_pseudo.
+The only functional difference is that new_inode places the inodes
+on the sb->s_inodes list.
+
+I wrote a small test program and I can verify that without changes it
+can trigger this issue, and by replacing new_inode_pseudo with
+new_inode the issues goes away.
+
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/000000000000d788c905a7dfa3f4@google.com
+Reported-by: syzbot+7d2debdcdb3cb93c1e5e@syzkaller.appspotmail.com
+Fixes: 0097875bd415 ("proc: Implement /proc/thread-self to point at the directory of the current thread")
+Fixes: 021ada7dff22 ("procfs: switch /proc/self away from proc_dir_entry")
+Fixes: 51f0885e5415 ("vfs,proc: guarantee unique inodes in /proc")
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/proc/inode.c       |    2 +-
+ fs/proc/self.c        |    2 +-
+ fs/proc/thread_self.c |    2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/fs/proc/inode.c
++++ b/fs/proc/inode.c
+@@ -448,7 +448,7 @@ const struct inode_operations proc_link_
+ 
+ struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de)
+ {
+-      struct inode *inode = new_inode_pseudo(sb);
++      struct inode *inode = new_inode(sb);
+ 
+       if (inode) {
+               inode->i_ino = de->low_ino;
+--- a/fs/proc/self.c
++++ b/fs/proc/self.c
+@@ -43,7 +43,7 @@ int proc_setup_self(struct super_block *
+       inode_lock(root_inode);
+       self = d_alloc_name(s->s_root, "self");
+       if (self) {
+-              struct inode *inode = new_inode_pseudo(s);
++              struct inode *inode = new_inode(s);
+               if (inode) {
+                       inode->i_ino = self_inum;
+                       inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode);
+--- a/fs/proc/thread_self.c
++++ b/fs/proc/thread_self.c
+@@ -43,7 +43,7 @@ int proc_setup_thread_self(struct super_
+       inode_lock(root_inode);
+       thread_self = d_alloc_name(s->s_root, "thread-self");
+       if (thread_self) {
+-              struct inode *inode = new_inode_pseudo(s);
++              struct inode *inode = new_inode(s);
+               if (inode) {
+                       inode->i_ino = thread_self_inum;
+                       inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode);

diff --git a/queue-5.6/remoteproc-fall-back-to-using-parent-memory-pool-if-no-dedicated-available.patch b/queue-5.6/remoteproc-fall-back-to-using-parent-memory-pool-if-no-dedicated-available.patch
new file mode 100644 (file)
index 0000000..1752e2e
--- /dev/null
+++ b/queue-5.6/remoteproc-fall-back-to-using-parent-memory-pool-if-no-dedicated-available.patch
@@ -0,0 +1,52 @@
+From db9178a4f8c4e523f824892cb8bab00961b07385 Mon Sep 17 00:00:00 2001
+From: Tero Kristo <t-kristo@ti.com>
+Date: Mon, 20 Apr 2020 11:05:59 -0500
+Subject: remoteproc: Fall back to using parent memory pool if no dedicated available
+
+From: Tero Kristo <t-kristo@ti.com>
+
+commit db9178a4f8c4e523f824892cb8bab00961b07385 upstream.
+
+In some cases, like with OMAP remoteproc, we are not creating dedicated
+memory pool for the virtio device. Instead, we use the same memory pool
+for all shared memories. The current virtio memory pool handling forces
+a split between these two, as a separate device is created for it,
+causing memory to be allocated from bad location if the dedicated pool
+is not available. Fix this by falling back to using the parent device
+memory pool if dedicated is not available.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
+Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
+Signed-off-by: Tero Kristo <t-kristo@ti.com>
+Signed-off-by: Suman Anna <s-anna@ti.com>
+Link: https://lore.kernel.org/r/20200420160600.10467-2-s-anna@ti.com
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/remoteproc/remoteproc_virtio.c |   12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/remoteproc/remoteproc_virtio.c
++++ b/drivers/remoteproc/remoteproc_virtio.c
+@@ -375,6 +375,18 @@ int rproc_add_virtio_dev(struct rproc_vd
+                               goto out;
+                       }
+               }
++      } else {
++              struct device_node *np = rproc->dev.parent->of_node;
++
++              /*
++               * If we don't have dedicated buffer, just attempt to re-assign
++               * the reserved memory from our parent. A default memory-region
++               * at index 0 from the parent's memory-regions is assigned for
++               * the rvdev dev to allocate from. Failure is non-critical and
++               * the allocations will fall back to global pools, so don't
++               * check return value either.
++               */
++              of_reserved_mem_device_init_by_idx(dev, np, 0);
+       }
+ 
+       /* Allocate virtio device */

diff --git a/queue-5.6/remoteproc-fix-and-restore-the-parenting-hierarchy-for-vdev.patch b/queue-5.6/remoteproc-fix-and-restore-the-parenting-hierarchy-for-vdev.patch
new file mode 100644 (file)
index 0000000..5a56759
--- /dev/null
+++ b/queue-5.6/remoteproc-fix-and-restore-the-parenting-hierarchy-for-vdev.patch
@@ -0,0 +1,46 @@
+From c774ad010873bb89dcc0cdcb1e96aef6664d8caf Mon Sep 17 00:00:00 2001
+From: Suman Anna <s-anna@ti.com>
+Date: Mon, 20 Apr 2020 11:06:00 -0500
+Subject: remoteproc: Fix and restore the parenting hierarchy for vdev
+
+From: Suman Anna <s-anna@ti.com>
+
+commit c774ad010873bb89dcc0cdcb1e96aef6664d8caf upstream.
+
+The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
+dma memory pool") has introduced a new vdev subdevice for each vdev
+declared in the firmware resource table and made it as the parent for the
+created virtio rpmsg devices instead of the previous remoteproc device.
+This changed the overall parenting hierarchy for the rpmsg devices, which
+were children of virtio devices, and does not allow the corresponding
+rpmsg drivers to retrieve the parent rproc device through the
+rproc_get_by_child() API.
+
+Fix this by restoring the remoteproc device as the parent. The new vdev
+subdevice can continue to inherit the DMA attributes from the remoteproc's
+parent device (actual platform device).
+
+Cc: stable@vger.kernel.org
+Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
+Signed-off-by: Suman Anna <s-anna@ti.com>
+Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
+Link: https://lore.kernel.org/r/20200420160600.10467-3-s-anna@ti.com
+Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/remoteproc/remoteproc_core.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/remoteproc/remoteproc_core.c
++++ b/drivers/remoteproc/remoteproc_core.c
+@@ -510,7 +510,7 @@ static int rproc_handle_vdev(struct rpro
+ 
+       /* Initialise vdev subdevice */
+       snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
+-      rvdev->dev.parent = rproc->dev.parent;
++      rvdev->dev.parent = &rproc->dev;
+       rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
+       rvdev->dev.release = rproc_rvdev_release;
+       dev_set_name(&rvdev->dev, "%s#%s", dev_name(rvdev->dev.parent), name);

diff --git a/queue-5.6/series b/queue-5.6/series
index 03f95e48a0d4dbef6654cd3a6c24759f780dc5d8..41d4c89d104443b1ab17556d10dcea27510270f4 100644 (file)
--- a/queue-5.6/series
+++ b/queue-5.6/series
@@ -112,3 +112,8 @@ net-mlx5e-fix-repeated-xsk-usage-on-one-channel.patch
 net-cadence-macb-disable-napi-on-error.patch
 net-macb-only-disable-napi-on-the-actual-error-path.patch
 net-mlx5-disable-reload-while-removing-the-device.patch
+ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch
+ovl-initialize-error-in-ovl_copy_xattr.patch
+proc-use-new_inode-not-new_inode_pseudo.patch
+remoteproc-fall-back-to-using-parent-memory-pool-if-no-dedicated-available.patch
+remoteproc-fix-and-restore-the-parenting-hierarchy-for-vdev.patch