6.6-stable patches

added patches:
	tracing-have-process_string-also-allow-arrays.patch

diff --git a/queue-6.6/series b/queue-6.6/series
index 78a82af01fca583e9389bba49e0f7dc9b02668dc..925cf5ca87f54b6d84aa7734bb54497411b020ba 100644 (file)
--- a/queue-6.6/series
+++ b/queue-6.6/series
@@ -115,3 +115,4 @@ f2fs-fix-to-wait-dio-completion.patch
 selinux-ignore-unknown-extended-permissions.patch
 btrfs-fix-use-after-free-in-btrfs_encoded_read_endio.patch
 mmc-sdhci-msm-fix-crypto-key-eviction.patch
+tracing-have-process_string-also-allow-arrays.patch

diff --git a/queue-6.6/tracing-have-process_string-also-allow-arrays.patch b/queue-6.6/tracing-have-process_string-also-allow-arrays.patch
new file mode 100644 (file)
index 0000000..f90111d
--- /dev/null
+++ b/queue-6.6/tracing-have-process_string-also-allow-arrays.patch
@@ -0,0 +1,67 @@
+From afc6717628f959941d7b33728570568b4af1c4b8 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Tue, 31 Dec 2024 00:06:46 -0500
+Subject: tracing: Have process_string() also allow arrays
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit afc6717628f959941d7b33728570568b4af1c4b8 upstream.
+
+In order to catch a common bug where a TRACE_EVENT() TP_fast_assign()
+assigns an address of an allocated string to the ring buffer and then
+references it in TP_printk(), which can be executed hours later when the
+string is free, the function test_event_printk() runs on all events as
+they are registered to make sure there's no unwanted dereferencing.
+
+It calls process_string() to handle cases in TP_printk() format that has
+"%s". It returns whether or not the string is safe. But it can have some
+false positives.
+
+For instance, xe_bo_move() has:
+
+ TP_printk("move_lacks_source:%s, migrate object %p [size %zu] from %s to %s device_id:%s",
+            __entry->move_lacks_source ? "yes" : "no", __entry->bo, __entry->size,
+            xe_mem_type_to_name[__entry->old_placement],
+            xe_mem_type_to_name[__entry->new_placement], __get_str(device_id))
+
+Where the "%s" references into xe_mem_type_to_name[]. This is an array of
+pointers that should be safe for the event to access. Instead of flagging
+this as a bad reference, if a reference points to an array, where the
+record field is the index, consider it safe.
+
+Link: https://lore.kernel.org/all/9dee19b6185d325d0e6fa5f7cbba81d007d99166.camel@sapience.com/
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Link: https://lore.kernel.org/20241231000646.324fb5f7@gandalf.local.home
+Fixes: 65a25d9f7ac02 ("tracing: Add "%s" check in test_event_printk()")
+Reported-by: Genes Lists <lists@sapience.com>
+Tested-by: Gene C <arch@sapience.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events.c |   12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/kernel/trace/trace_events.c
++++ b/kernel/trace/trace_events.c
+@@ -361,6 +361,18 @@ static bool process_string(const char *f
+       } while (s < e);
+ 
+       /*
++       * Check for arrays. If the argument has: foo[REC->val]
++       * then it is very likely that foo is an array of strings
++       * that are safe to use.
++       */
++      r = strstr(s, "[");
++      if (r && r < e) {
++              r = strstr(r, "REC->");
++              if (r && r < e)
++                      return true;
++      }
++
++      /*
+        * If there's any strings in the argument consider this arg OK as it
+        * could be: REC->field ? "foo" : "bar" and we don't want to get into
+        * verifying that logic here.