From 616ebb571f3dd6a249d6d828fab245644203c9ce Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 16 Jun 2020 09:53:56 +0200 Subject: [PATCH] 5.7-stable patches added patches: exfat-fix-incorrect-update-of-stream-entry-in-__exfat_truncate.patch exfat-fix-memory-leak-in-exfat_parse_param.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 --- ...-of-stream-entry-in-__exfat_truncate.patch | 41 +++++++++ ...fix-memory-leak-in-exfat_parse_param.patch | 86 +++++++++++++++++++ ...s-access-warning-in-ovl_check_fb_len.patch | 43 ++++++++++ ...l-initialize-error-in-ovl_copy_xattr.patch | 46 ++++++++++ ...c-use-new_inode-not-new_inode_pseudo.patch | 83 ++++++++++++++++++ ...emory-pool-if-no-dedicated-available.patch | 52 +++++++++++ ...ore-the-parenting-hierarchy-for-vdev.patch | 46 ++++++++++ queue-5.7/series | 7 ++ 8 files changed, 404 insertions(+) create mode 100644 queue-5.7/exfat-fix-incorrect-update-of-stream-entry-in-__exfat_truncate.patch create mode 100644 queue-5.7/exfat-fix-memory-leak-in-exfat_parse_param.patch create mode 100644 queue-5.7/ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch create mode 100644 queue-5.7/ovl-initialize-error-in-ovl_copy_xattr.patch create mode 100644 queue-5.7/proc-use-new_inode-not-new_inode_pseudo.patch create mode 100644 queue-5.7/remoteproc-fall-back-to-using-parent-memory-pool-if-no-dedicated-available.patch create mode 100644 queue-5.7/remoteproc-fix-and-restore-the-parenting-hierarchy-for-vdev.patch diff --git a/queue-5.7/exfat-fix-incorrect-update-of-stream-entry-in-__exfat_truncate.patch b/queue-5.7/exfat-fix-incorrect-update-of-stream-entry-in-__exfat_truncate.patch new file mode 100644 index 00000000000..0c628bc71dc --- /dev/null +++ b/queue-5.7/exfat-fix-incorrect-update-of-stream-entry-in-__exfat_truncate.patch @@ -0,0 +1,41 @@ +From 29bbb14bfc80dd760b07d2be0a27e610562982e3 Mon Sep 17 00:00:00 2001 +From: Namjae Jeon +Date: Thu, 4 Jun 2020 08:05:31 +0900 +Subject: exfat: fix incorrect update of stream entry in __exfat_truncate() + +From: Namjae Jeon + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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) { diff --git a/queue-5.7/exfat-fix-memory-leak-in-exfat_parse_param.patch b/queue-5.7/exfat-fix-memory-leak-in-exfat_parse_param.patch new file mode 100644 index 00000000000..6bd070b3486 --- /dev/null +++ b/queue-5.7/exfat-fix-memory-leak-in-exfat_parse_param.patch @@ -0,0 +1,86 @@ +From f341a7d8dcc4e3d01544d7bc145633f062ef6249 Mon Sep 17 00:00:00 2001 +From: Al Viro +Date: Wed, 3 Jun 2020 09:48:36 +0900 +Subject: exfat: fix memory leak in exfat_parse_param() + +From: Al Viro + +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 +Signed-off-by: Al Viro +Signed-off-by: Namjae Jeon +Signed-off-by: Greg Kroah-Hartman + +--- + 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 = { diff --git a/queue-5.7/ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch b/queue-5.7/ovl-fix-out-of-bounds-access-warning-in-ovl_check_fb_len.patch new file mode 100644 index 00000000000..098296aad0b --- /dev/null +++ b/queue-5.7/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 +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 + +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: # v5.5 +Signed-off-by: Amir Goldstein +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + diff --git a/queue-5.7/ovl-initialize-error-in-ovl_copy_xattr.patch b/queue-5.7/ovl-initialize-error-in-ovl_copy_xattr.patch new file mode 100644 index 00000000000..6a5cb3434de --- /dev/null +++ b/queue-5.7/ovl-initialize-error-in-ovl_copy_xattr.patch @@ -0,0 +1,46 @@ +From 520da69d265a91c6536c63851cbb8a53946974f0 Mon Sep 17 00:00:00 2001 +From: Yuxuan Shui +Date: Wed, 27 May 2020 04:08:02 +0100 +Subject: ovl: initialize error in ovl_copy_xattr + +From: Yuxuan Shui + +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 +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 +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + 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) || diff --git a/queue-5.7/proc-use-new_inode-not-new_inode_pseudo.patch b/queue-5.7/proc-use-new_inode-not-new_inode_pseudo.patch new file mode 100644 index 00000000000..06d5c6798c5 --- /dev/null +++ b/queue-5.7/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" +Date: Fri, 12 Jun 2020 09:42:03 -0500 +Subject: proc: Use new_inode not new_inode_pseudo + +From: Eric W. Biederman + +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" +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-5.7/remoteproc-fall-back-to-using-parent-memory-pool-if-no-dedicated-available.patch b/queue-5.7/remoteproc-fall-back-to-using-parent-memory-pool-if-no-dedicated-available.patch new file mode 100644 index 00000000000..ce5564f6d39 --- /dev/null +++ b/queue-5.7/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 +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 + +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 +Acked-by: Arnaud Pouliquen +Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool") +Signed-off-by: Tero Kristo +Signed-off-by: Suman Anna +Link: https://lore.kernel.org/r/20200420160600.10467-2-s-anna@ti.com +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ diff --git a/queue-5.7/remoteproc-fix-and-restore-the-parenting-hierarchy-for-vdev.patch b/queue-5.7/remoteproc-fix-and-restore-the-parenting-hierarchy-for-vdev.patch new file mode 100644 index 00000000000..339a24306b2 --- /dev/null +++ b/queue-5.7/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 +Date: Mon, 20 Apr 2020 11:06:00 -0500 +Subject: remoteproc: Fix and restore the parenting hierarchy for vdev + +From: Suman Anna + +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 +Reviewed-by: Mathieu Poirier +Acked-by: Arnaud Pouliquen +Link: https://lore.kernel.org/r/20200420160600.10467-3-s-anna@ti.com +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-5.7/series b/queue-5.7/series index f2997d579df..441da5e38f7 100644 --- a/queue-5.7/series +++ b/queue-5.7/series @@ -112,3 +112,10 @@ net-ethernet-ti-ale-fix-allmulti-for-nu-type-ale.patch 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 -- 2.47.3