5.15-stable patches

added patches:
	__follow_mount_rcu-verify-that-mount_lock-remains-unchanged.patch
	spmi-trace-fix-stack-out-of-bound-access-in-spmi-tracing-functions.patch

diff --git a/queue-5.15/__follow_mount_rcu-verify-that-mount_lock-remains-unchanged.patch b/queue-5.15/__follow_mount_rcu-verify-that-mount_lock-remains-unchanged.patch
new file mode 100644 (file)
index 0000000..2e1c932
--- /dev/null
+++ b/queue-5.15/__follow_mount_rcu-verify-that-mount_lock-remains-unchanged.patch
@@ -0,0 +1,46 @@
+From 20aac6c60981f5bfacd66661d090d907bf1482f0 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Mon, 4 Jul 2022 17:26:29 -0400
+Subject: __follow_mount_rcu(): verify that mount_lock remains unchanged
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit 20aac6c60981f5bfacd66661d090d907bf1482f0 upstream.
+
+Validate mount_lock seqcount as soon as we cross into mount in RCU
+mode.  Sure, ->mnt_root is pinned and will remain so until we
+do rcu_read_unlock() anyway, and we will eventually fail to unlazy if
+the mount_lock had been touched, but we might run into a hard error
+(e.g. -ENOENT) before trying to unlazy.  And it's possible to end
+up with RCU pathwalk racing with rename() and umount() in a way
+that would fail with -ENOENT while non-RCU pathwalk would've
+succeeded with any timings.
+
+Once upon a time we hadn't needed that, but analysis had been subtle,
+brittle and went out of window as soon as RENAME_EXCHANGE had been
+added.
+
+It's narrow, hard to hit and won't get you anything other than
+stray -ENOENT that could be arranged in much easier way with the
+same priveleges, but it's a bug all the same.
+
+Cc: stable@kernel.org
+X-sky-is-falling: unlikely
+Fixes: da1ce0670c14 "vfs: add cross-rename"
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/namei.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/namei.c
++++ b/fs/namei.c
+@@ -1461,6 +1461,8 @@ static bool __follow_mount_rcu(struct na
+                                * becoming unpinned.
+                                */
+                               flags = dentry->d_flags;
++                              if (read_seqretry(&mount_lock, nd->m_seq))
++                                      return false;
+                               continue;
+                       }
+                       if (read_seqretry(&mount_lock, nd->m_seq))

diff --git a/queue-5.15/series b/queue-5.15/series
index 710cdcd1aea2a928b6014dcdf7ad8ebef73bba3d..23061559f63c9399c5bea3fdc2e82eb63b1ee2a1 100644 (file)
--- a/queue-5.15/series
+++ b/queue-5.15/series
@@ -689,3 +689,5 @@ x86-olpc-fix-logical-not-is-only-applied-to-the-left-hand-side.patch
 smb3-fix-lease-break-timeout-when-multiple-deferred-close-handles-for-the-same-file.patch
 posix-cpu-timers-cleanup-cpu-timers-before-freeing-them-during-exec.patch
 input-gscps2-check-return-value-of-ioremap-in-gscps2_probe.patch
+__follow_mount_rcu-verify-that-mount_lock-remains-unchanged.patch
+spmi-trace-fix-stack-out-of-bound-access-in-spmi-tracing-functions.patch

diff --git a/queue-5.15/spmi-trace-fix-stack-out-of-bound-access-in-spmi-tracing-functions.patch b/queue-5.15/spmi-trace-fix-stack-out-of-bound-access-in-spmi-tracing-functions.patch
new file mode 100644 (file)
index 0000000..26b6926
--- /dev/null
+++ b/queue-5.15/spmi-trace-fix-stack-out-of-bound-access-in-spmi-tracing-functions.patch
@@ -0,0 +1,110 @@
+From 2af28b241eea816e6f7668d1954f15894b45d7e3 Mon Sep 17 00:00:00 2001
+From: David Collins <quic_collinsd@quicinc.com>
+Date: Mon, 27 Jun 2022 16:55:12 -0700
+Subject: spmi: trace: fix stack-out-of-bound access in SPMI tracing functions
+
+From: David Collins <quic_collinsd@quicinc.com>
+
+commit 2af28b241eea816e6f7668d1954f15894b45d7e3 upstream.
+
+trace_spmi_write_begin() and trace_spmi_read_end() both call
+memcpy() with a length of "len + 1".  This leads to one extra
+byte being read beyond the end of the specified buffer.  Fix
+this out-of-bound memory access by using a length of "len"
+instead.
+
+Here is a KASAN log showing the issue:
+
+BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234
+Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314
+...
+Call trace:
+ dump_backtrace+0x0/0x3e8
+ show_stack+0x2c/0x3c
+ dump_stack_lvl+0xdc/0x11c
+ print_address_description+0x74/0x384
+ kasan_report+0x188/0x268
+ kasan_check_range+0x270/0x2b0
+ memcpy+0x90/0xe8
+ trace_event_raw_event_spmi_read_end+0x1d0/0x234
+ spmi_read_cmd+0x294/0x3ac
+ spmi_ext_register_readl+0x84/0x9c
+ regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]
+ _regmap_raw_read+0x40c/0x754
+ regmap_raw_read+0x3a0/0x514
+ regmap_bulk_read+0x418/0x494
+ adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]
+ ...
+ __arm64_sys_read+0x4c/0x60
+ invoke_syscall+0x80/0x218
+ el0_svc_common+0xec/0x1c8
+ ...
+
+addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:
+ adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]
+
+this frame has 1 object:
+ [32, 33) 'status'
+
+Memory state around the buggy address:
+ ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
+ ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
+>ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00
+                                           ^
+ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00
+==================================================================
+
+Fixes: a9fce374815d ("spmi: add command tracepoints for SPMI")
+Cc: stable@vger.kernel.org
+Reviewed-by: Stephen Boyd <sboyd@kernel.org>
+Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: David Collins <quic_collinsd@quicinc.com>
+Link: https://lore.kernel.org/r/20220627235512.2272783-1-quic_collinsd@quicinc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/trace/events/spmi.h |   12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/include/trace/events/spmi.h
++++ b/include/trace/events/spmi.h
+@@ -21,15 +21,15 @@ TRACE_EVENT(spmi_write_begin,
+               __field         ( u8,         sid       )
+               __field         ( u16,        addr      )
+               __field         ( u8,         len       )
+-              __dynamic_array ( u8,   buf,  len + 1   )
++              __dynamic_array ( u8,   buf,  len       )
+       ),
+ 
+       TP_fast_assign(
+               __entry->opcode = opcode;
+               __entry->sid    = sid;
+               __entry->addr   = addr;
+-              __entry->len    = len + 1;
+-              memcpy(__get_dynamic_array(buf), buf, len + 1);
++              __entry->len    = len;
++              memcpy(__get_dynamic_array(buf), buf, len);
+       ),
+ 
+       TP_printk("opc=%d sid=%02d addr=0x%04x len=%d buf=0x[%*phD]",
+@@ -92,7 +92,7 @@ TRACE_EVENT(spmi_read_end,
+               __field         ( u16,        addr      )
+               __field         ( int,        ret       )
+               __field         ( u8,         len       )
+-              __dynamic_array ( u8,   buf,  len + 1   )
++              __dynamic_array ( u8,   buf,  len       )
+       ),
+ 
+       TP_fast_assign(
+@@ -100,8 +100,8 @@ TRACE_EVENT(spmi_read_end,
+               __entry->sid    = sid;
+               __entry->addr   = addr;
+               __entry->ret    = ret;
+-              __entry->len    = len + 1;
+-              memcpy(__get_dynamic_array(buf), buf, len + 1);
++              __entry->len    = len;
++              memcpy(__get_dynamic_array(buf), buf, len);
+       ),
+ 
+       TP_printk("opc=%d sid=%02d addr=0x%04x ret=%d len=%02d buf=0x[%*phD]",