]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.19-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 7 Nov 2022 15:34:35 +0000 (16:34 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 7 Nov 2022 15:34:35 +0000 (16:34 +0100)
added patches:
capabilities-fix-potential-memleak-on-error-path-from-vfs_getxattr_alloc.patch
fuse-add-file_modified-to-fallocate.patch
kprobe-reverse-kp-flags-when-arm_kprobe-failed.patch
tracing-histogram-update-document-for-keys_max-size.patch

queue-4.19/capabilities-fix-potential-memleak-on-error-path-from-vfs_getxattr_alloc.patch [new file with mode: 0644]
queue-4.19/fuse-add-file_modified-to-fallocate.patch [new file with mode: 0644]
queue-4.19/kprobe-reverse-kp-flags-when-arm_kprobe-failed.patch [new file with mode: 0644]
queue-4.19/series
queue-4.19/tracing-histogram-update-document-for-keys_max-size.patch [new file with mode: 0644]

diff --git a/queue-4.19/capabilities-fix-potential-memleak-on-error-path-from-vfs_getxattr_alloc.patch b/queue-4.19/capabilities-fix-potential-memleak-on-error-path-from-vfs_getxattr_alloc.patch
new file mode 100644 (file)
index 0000000..1f8cbb0
--- /dev/null
@@ -0,0 +1,51 @@
+From 8cf0a1bc12870d148ae830a4ba88cfdf0e879cee Mon Sep 17 00:00:00 2001
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+Date: Tue, 25 Oct 2022 21:33:57 +0800
+Subject: capabilities: fix potential memleak on error path from vfs_getxattr_alloc()
+
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+
+commit 8cf0a1bc12870d148ae830a4ba88cfdf0e879cee upstream.
+
+In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to
+complete the memory allocation of tmpbuf, if we have completed
+the memory allocation of tmpbuf, but failed to call handler->get(...),
+there will be a memleak in below logic:
+
+  |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...)
+    |           /* ^^^ alloc for tmpbuf */
+    |-- value = krealloc(*xattr_value, error + 1, flags)
+    |           /* ^^^ alloc memory */
+    |-- error = handler->get(handler, ...)
+    |           /* error! */
+    |-- *xattr_value = value
+    |           /* xattr_value is &tmpbuf (memory leak!) */
+
+So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it.
+
+Cc: stable@vger.kernel.org
+Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
+Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Acked-by: Serge Hallyn <serge@hallyn.com>
+[PM: subject line and backtrace tweaks]
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ security/commoncap.c |    6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/security/commoncap.c
++++ b/security/commoncap.c
+@@ -397,8 +397,10 @@ int cap_inode_getsecurity(struct inode *
+                                &tmpbuf, size, GFP_NOFS);
+       dput(dentry);
+-      if (ret < 0 || !tmpbuf)
+-              return ret;
++      if (ret < 0 || !tmpbuf) {
++              size = ret;
++              goto out_free;
++      }
+       fs_ns = inode->i_sb->s_user_ns;
+       cap = (struct vfs_cap_data *) tmpbuf;
diff --git a/queue-4.19/fuse-add-file_modified-to-fallocate.patch b/queue-4.19/fuse-add-file_modified-to-fallocate.patch
new file mode 100644 (file)
index 0000000..9991d5d
--- /dev/null
@@ -0,0 +1,33 @@
+From 4a6f278d4827b59ba26ceae0ff4529ee826aa258 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Fri, 28 Oct 2022 14:25:20 +0200
+Subject: fuse: add file_modified() to fallocate
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+commit 4a6f278d4827b59ba26ceae0ff4529ee826aa258 upstream.
+
+Add missing file_modified() call to fuse_file_fallocate().  Without this
+fallocate on fuse failed to clear privileges.
+
+Fixes: 05ba1f082300 ("fuse: add FALLOCATE operation")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/file.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/fuse/file.c
++++ b/fs/fuse/file.c
+@@ -3012,6 +3012,10 @@ static long fuse_file_fallocate(struct f
+                       goto out;
+       }
++      err = file_modified(file);
++      if (err)
++              goto out;
++
+       if (!(mode & FALLOC_FL_KEEP_SIZE))
+               set_bit(FUSE_I_SIZE_UNSTABLE, &fi->state);
diff --git a/queue-4.19/kprobe-reverse-kp-flags-when-arm_kprobe-failed.patch b/queue-4.19/kprobe-reverse-kp-flags-when-arm_kprobe-failed.patch
new file mode 100644 (file)
index 0000000..f765cc3
--- /dev/null
@@ -0,0 +1,41 @@
+From 4a6f316d6855a434f56dbbeba05e14c01acde8f8 Mon Sep 17 00:00:00 2001
+From: Li Qiang <liq3ea@163.com>
+Date: Fri, 4 Nov 2022 08:49:31 +0900
+Subject: kprobe: reverse kp->flags when arm_kprobe failed
+
+From: Li Qiang <liq3ea@163.com>
+
+commit 4a6f316d6855a434f56dbbeba05e14c01acde8f8 upstream.
+
+In aggregate kprobe case, when arm_kprobe failed,
+we need set the kp->flags with KPROBE_FLAG_DISABLED again.
+If not, the 'kp' kprobe will been considered as enabled
+but it actually not enabled.
+
+Link: https://lore.kernel.org/all/20220902155820.34755-1-liq3ea@163.com/
+
+Fixes: 12310e343755 ("kprobes: Propagate error from arm_kprobe_ftrace()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Li Qiang <liq3ea@163.com>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/kprobes.c |    5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/kernel/kprobes.c
++++ b/kernel/kprobes.c
+@@ -2172,8 +2172,11 @@ int enable_kprobe(struct kprobe *kp)
+       if (!kprobes_all_disarmed && kprobe_disabled(p)) {
+               p->flags &= ~KPROBE_FLAG_DISABLED;
+               ret = arm_kprobe(p);
+-              if (ret)
++              if (ret) {
+                       p->flags |= KPROBE_FLAG_DISABLED;
++                      if (p != kp)
++                              kp->flags |= KPROBE_FLAG_DISABLED;
++              }
+       }
+ out:
+       mutex_unlock(&kprobe_mutex);
index 6046f58cdf381f7b4a6a3caa47f37c286cd4ba27..c030cef1469f5036633ad6642b52db137377a354 100644 (file)
@@ -31,3 +31,7 @@ bluetooth-l2cap-fix-attempting-to-access-uninitialized-memory.patch
 block-bfq-protect-bfqd-queued-by-bfqd-lock.patch
 btrfs-fix-type-of-parameter-generation-in-btrfs_get_dentry.patch
 tcp-udp-make-early_demux-back-namespacified.patch
+kprobe-reverse-kp-flags-when-arm_kprobe-failed.patch
+tracing-histogram-update-document-for-keys_max-size.patch
+capabilities-fix-potential-memleak-on-error-path-from-vfs_getxattr_alloc.patch
+fuse-add-file_modified-to-fallocate.patch
diff --git a/queue-4.19/tracing-histogram-update-document-for-keys_max-size.patch b/queue-4.19/tracing-histogram-update-document-for-keys_max-size.patch
new file mode 100644 (file)
index 0000000..00e2179
--- /dev/null
@@ -0,0 +1,33 @@
+From a635beeacc6d56d2b71c39e6c0103f85b53d108e Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Mon, 17 Oct 2022 10:38:06 +0000
+Subject: tracing/histogram: Update document for KEYS_MAX size
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit a635beeacc6d56d2b71c39e6c0103f85b53d108e upstream.
+
+After commit 4f36c2d85ced ("tracing: Increase tracing map KEYS_MAX size"),
+'keys' supports up to three fields.
+
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Cc: stable@vger.kernel.org
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Link: https://lore.kernel.org/r/20221017103806.2479139-1-zhengyejian1@huawei.com
+Signed-off-by: Jonathan Corbet <corbet@lwn.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/trace/histogram.rst |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/trace/histogram.rst
++++ b/Documentation/trace/histogram.rst
+@@ -39,7 +39,7 @@ Documentation written by Tom Zanussi
+   will use the event's kernel stacktrace as the key.  The keywords
+   'keys' or 'key' can be used to specify keys, and the keywords
+   'values', 'vals', or 'val' can be used to specify values.  Compound
+-  keys consisting of up to two fields can be specified by the 'keys'
++  keys consisting of up to three fields can be specified by the 'keys'
+   keyword.  Hashing a compound key produces a unique entry in the
+   table for each unique combination of component keys, and can be
+   useful for providing more fine-grained summaries of event data.