--- /dev/null
+From 29bbb14bfc80dd760b07d2be0a27e610562982e3 Mon Sep 17 00:00:00 2001
+From: Namjae Jeon <namjae.jeon@samsung.com>
+Date: Thu, 4 Jun 2020 08:05:31 +0900
+Subject: exfat: fix incorrect update of stream entry in __exfat_truncate()
+
+From: Namjae Jeon <namjae.jeon@samsung.com>
+
+commit 29bbb14bfc80dd760b07d2be0a27e610562982e3 upstream.
+
+At truncate, there is a problem of incorrect updating in the file entry
+pointer instead of stream entry. This will cause the problem of
+overwriting the time field of the file entry to new_size. Fix it to
+update stream entry.
+
+Fixes: 98d917047e8b ("exfat: add file operations")
+Cc: stable@vger.kernel.org # v5.7
+Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exfat/file.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/fs/exfat/file.c
++++ b/fs/exfat/file.c
+@@ -170,11 +170,11 @@ int __exfat_truncate(struct inode *inode
+
+ /* File size should be zero if there is no cluster allocated */
+ if (ei->start_clu == EXFAT_EOF_CLUSTER) {
+- ep->dentry.stream.valid_size = 0;
+- ep->dentry.stream.size = 0;
++ ep2->dentry.stream.valid_size = 0;
++ ep2->dentry.stream.size = 0;
+ } else {
+- ep->dentry.stream.valid_size = cpu_to_le64(new_size);
+- ep->dentry.stream.size = ep->dentry.stream.valid_size;
++ ep2->dentry.stream.valid_size = cpu_to_le64(new_size);
++ ep2->dentry.stream.size = ep->dentry.stream.valid_size;
+ }
+
+ if (new_size == 0) {
--- /dev/null
+From f341a7d8dcc4e3d01544d7bc145633f062ef6249 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Wed, 3 Jun 2020 09:48:36 +0900
+Subject: exfat: fix memory leak in exfat_parse_param()
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit f341a7d8dcc4e3d01544d7bc145633f062ef6249 upstream.
+
+butt3rflyh4ck reported memory leak found by syzkaller.
+
+A param->string held by exfat_mount_options.
+
+BUG: memory leak
+
+unreferenced object 0xffff88801972e090 (size 8):
+ comm "syz-executor.2", pid 16298, jiffies 4295172466 (age 14.060s)
+ hex dump (first 8 bytes):
+ 6b 6f 69 38 2d 75 00 00 koi8-u..
+ backtrace:
+ [<000000005bfe35d6>] kstrdup+0x36/0x70 mm/util.c:60
+ [<0000000018ed3277>] exfat_parse_param+0x160/0x5e0
+fs/exfat/super.c:276
+ [<000000007680462b>] vfs_parse_fs_param+0x2b4/0x610
+fs/fs_context.c:147
+ [<0000000097c027f2>] vfs_parse_fs_string+0xe6/0x150
+fs/fs_context.c:191
+ [<00000000371bf78f>] generic_parse_monolithic+0x16f/0x1f0
+fs/fs_context.c:231
+ [<000000005ce5eb1b>] do_new_mount fs/namespace.c:2812 [inline]
+ [<000000005ce5eb1b>] do_mount+0x12bb/0x1b30 fs/namespace.c:3141
+ [<00000000b642040c>] __do_sys_mount fs/namespace.c:3350 [inline]
+ [<00000000b642040c>] __se_sys_mount fs/namespace.c:3327 [inline]
+ [<00000000b642040c>] __x64_sys_mount+0x18f/0x230 fs/namespace.c:3327
+ [<000000003b024e98>] do_syscall_64+0xf6/0x7d0
+arch/x86/entry/common.c:295
+ [<00000000ce2b698c>] entry_SYSCALL_64_after_hwframe+0x49/0xb3
+
+exfat_free() should call exfat_free_iocharset(), to prevent a leak
+in case we fail after parsing iocharset= but before calling
+get_tree_bdev().
+
+Additionally, there's no point copying param->string in
+exfat_parse_param() - just steal it, leaving NULL in param->string.
+That's independent from the leak or fix thereof - it's simply
+avoiding an extra copy.
+
+Fixes: 719c1e182916 ("exfat: add super block operations")
+Cc: stable@vger.kernel.org # v5.7
+Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exfat/super.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/fs/exfat/super.c
++++ b/fs/exfat/super.c
+@@ -273,9 +273,8 @@ static int exfat_parse_param(struct fs_c
+ break;
+ case Opt_charset:
+ exfat_free_iocharset(sbi);
+- opts->iocharset = kstrdup(param->string, GFP_KERNEL);
+- if (!opts->iocharset)
+- return -ENOMEM;
++ opts->iocharset = param->string;
++ param->string = NULL;
+ break;
+ case Opt_errors:
+ opts->errors = result.uint_32;
+@@ -630,7 +629,12 @@ static int exfat_get_tree(struct fs_cont
+
+ static void exfat_free(struct fs_context *fc)
+ {
+- kfree(fc->s_fs_info);
++ struct exfat_sb_info *sbi = fc->s_fs_info;
++
++ if (sbi) {
++ exfat_free_iocharset(sbi);
++ kfree(sbi);
++ }
+ }
+
+ static const struct fs_context_operations exfat_context_ops = {
--- /dev/null
+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
+@@ -355,6 +355,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);
+ }
+
--- /dev/null
+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
+@@ -47,7 +47,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) ||
--- /dev/null
+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
+@@ -599,7 +599,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);
--- /dev/null
+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
+@@ -376,6 +376,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 */
--- /dev/null
+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
+@@ -517,7 +517,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);
net-ethernet-ti-am65-cpsw-nuss-fix-ale-parameters-init.patch
net-sched-export-__netdev_watchdog_up.patch
net-mlx5e-ct-fix-ipv6-nat-header-rewrite-actions.patch
+ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch
+ovl-initialize-error-in-ovl_copy_xattr.patch
+exfat-fix-memory-leak-in-exfat_parse_param.patch
+exfat-fix-incorrect-update-of-stream-entry-in-__exfat_truncate.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
projects / thirdparty / kernel / stable-queue.git / commitdiff
