]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
6.1-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 19 Apr 2024 10:43:12 +0000 (12:43 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 19 Apr 2024 10:43:12 +0000 (12:43 +0200)
added patches:
drm-i915-vma-fix-uaf-on-destroy-against-retire-race.patch
net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch
random-handle-creditable-entropy-from-atomic-process-context.patch
selftests-ftrace-limit-length-in-subsystem-enable-tests.patch
sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch

queue-6.1/drm-i915-vma-fix-uaf-on-destroy-against-retire-race.patch [new file with mode: 0644]
queue-6.1/net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch [new file with mode: 0644]
queue-6.1/random-handle-creditable-entropy-from-atomic-process-context.patch [new file with mode: 0644]
queue-6.1/selftests-ftrace-limit-length-in-subsystem-enable-tests.patch [new file with mode: 0644]
queue-6.1/series
queue-6.1/sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch [new file with mode: 0644]

diff --git a/queue-6.1/drm-i915-vma-fix-uaf-on-destroy-against-retire-race.patch b/queue-6.1/drm-i915-vma-fix-uaf-on-destroy-against-retire-race.patch
new file mode 100644 (file)
index 0000000..bf9c7c9
--- /dev/null
@@ -0,0 +1,194 @@
+From 0e45882ca829b26b915162e8e86dbb1095768e9e Mon Sep 17 00:00:00 2001
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Date: Tue, 5 Mar 2024 15:35:06 +0100
+Subject: drm/i915/vma: Fix UAF on destroy against retire race
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+
+commit 0e45882ca829b26b915162e8e86dbb1095768e9e upstream.
+
+Object debugging tools were sporadically reporting illegal attempts to
+free a still active i915 VMA object when parking a GT believed to be idle.
+
+[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
+[161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0
+...
+[161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1
+[161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022
+[161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]
+[161.360592] RIP: 0010:debug_print_object+0x80/0xb0
+...
+[161.361347] debug_object_free+0xeb/0x110
+[161.361362] i915_active_fini+0x14/0x130 [i915]
+[161.361866] release_references+0xfe/0x1f0 [i915]
+[161.362543] i915_vma_parked+0x1db/0x380 [i915]
+[161.363129] __gt_park+0x121/0x230 [i915]
+[161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915]
+
+That has been tracked down to be happening when another thread is
+deactivating the VMA inside __active_retire() helper, after the VMA's
+active counter has been already decremented to 0, but before deactivation
+of the VMA's object is reported to the object debugging tool.
+
+We could prevent from that race by serializing i915_active_fini() with
+__active_retire() via ref->tree_lock, but that wouldn't stop the VMA from
+being used, e.g. from __i915_vma_retire() called at the end of
+__active_retire(), after that VMA has been already freed by a concurrent
+i915_vma_destroy() on return from the i915_active_fini().  Then, we should
+rather fix the issue at the VMA level, not in i915_active.
+
+Since __i915_vma_parked() is called from __gt_park() on last put of the
+GT's wakeref, the issue could be addressed by holding the GT wakeref long
+enough for __active_retire() to complete before that wakeref is released
+and the GT parked.
+
+I believe the issue was introduced by commit d93939730347 ("drm/i915:
+Remove the vma refcount") which moved a call to i915_active_fini() from
+a dropped i915_vma_release(), called on last put of the removed VMA kref,
+to i915_vma_parked() processing path called on last put of a GT wakeref.
+However, its visibility to the object debugging tool was suppressed by a
+bug in i915_active that was fixed two weeks later with commit e92eb246feb9
+("drm/i915/active: Fix missing debug object activation").
+
+A VMA associated with a request doesn't acquire a GT wakeref by itself.
+Instead, it depends on a wakeref held directly by the request's active
+intel_context for a GT associated with its VM, and indirectly on that
+intel_context's engine wakeref if the engine belongs to the same GT as the
+VMA's VM.  Those wakerefs are released asynchronously to VMA deactivation.
+
+Fix the issue by getting a wakeref for the VMA's GT when activating it,
+and putting that wakeref only after the VMA is deactivated.  However,
+exclude global GTT from that processing path, otherwise the GPU never goes
+idle.  Since __i915_vma_retire() may be called from atomic contexts, use
+async variant of wakeref put.  Also, to avoid circular locking dependency,
+take care of acquiring the wakeref before VM mutex when both are needed.
+
+v7: Add inline comments with justifications for:
+    - using untracked variants of intel_gt_pm_get/put() (Nirmoy),
+    - using async variant of _put(),
+    - not getting the wakeref in case of a global GTT,
+    - always getting the first wakeref outside vm->mutex.
+v6: Since __i915_vma_active/retire() callbacks are not serialized, storing
+    a wakeref tracking handle inside struct i915_vma is not safe, and
+    there is no other good place for that.  Use untracked variants of
+    intel_gt_pm_get/put_async().
+v5: Replace "tile" with "GT" across commit description (Rodrigo),
+  - avoid mentioning multi-GT case in commit description (Rodrigo),
+  - explain why we need to take a temporary wakeref unconditionally inside
+    i915_vma_pin_ww() (Rodrigo).
+v4: Refresh on top of commit 5e4e06e4087e ("drm/i915: Track gt pm
+    wakerefs") (Andi),
+  - for more easy backporting, split out removal of former insufficient
+    workarounds and move them to separate patches (Nirmoy).
+  - clean up commit message and description a bit.
+v3: Identify root cause more precisely, and a commit to blame,
+  - identify and drop former workarounds,
+  - update commit message and description.
+v2: Get the wakeref before VM mutex to avoid circular locking dependency,
+  - drop questionable Fixes: tag.
+
+Fixes: d93939730347 ("drm/i915: Remove the vma refcount")
+Closes: https://gitlab.freedesktop.org/drm/intel/issues/8875
+Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Cc: Nirmoy Das <nirmoy.das@intel.com>
+Cc: Andi Shyti <andi.shyti@linux.intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Cc: stable@vger.kernel.org # v5.19+
+Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
+Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240305143747.335367-6-janusz.krzysztofik@linux.intel.com
+(cherry picked from commit f3c71b2ded5c4367144a810ef25f998fd1d6c381)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/i915_vma.c |   42 +++++++++++++++++++++++++++++++++-------
+ 1 file changed, 35 insertions(+), 7 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_vma.c
++++ b/drivers/gpu/drm/i915/i915_vma.c
+@@ -32,6 +32,7 @@
+ #include "gt/intel_engine.h"
+ #include "gt/intel_engine_heartbeat.h"
+ #include "gt/intel_gt.h"
++#include "gt/intel_gt_pm.h"
+ #include "gt/intel_gt_requests.h"
+ #include "i915_drv.h"
+@@ -98,12 +99,34 @@ static inline struct i915_vma *active_to
+ static int __i915_vma_active(struct i915_active *ref)
+ {
+-      return i915_vma_tryget(active_to_vma(ref)) ? 0 : -ENOENT;
++      struct i915_vma *vma = active_to_vma(ref);
++
++      if (!i915_vma_tryget(vma))
++              return -ENOENT;
++
++      /*
++       * Exclude global GTT VMA from holding a GT wakeref
++       * while active, otherwise GPU never goes idle.
++       */
++      if (!i915_vma_is_ggtt(vma))
++              intel_gt_pm_get(vma->vm->gt);
++
++      return 0;
+ }
+ static void __i915_vma_retire(struct i915_active *ref)
+ {
+-      i915_vma_put(active_to_vma(ref));
++      struct i915_vma *vma = active_to_vma(ref);
++
++      if (!i915_vma_is_ggtt(vma)) {
++              /*
++               * Since we can be called from atomic contexts,
++               * use an async variant of intel_gt_pm_put().
++               */
++              intel_gt_pm_put_async(vma->vm->gt);
++      }
++
++      i915_vma_put(vma);
+ }
+ static struct i915_vma *
+@@ -1365,7 +1388,7 @@ int i915_vma_pin_ww(struct i915_vma *vma
+       struct i915_vma_work *work = NULL;
+       struct dma_fence *moving = NULL;
+       struct i915_vma_resource *vma_res = NULL;
+-      intel_wakeref_t wakeref = 0;
++      intel_wakeref_t wakeref;
+       unsigned int bound;
+       int err;
+@@ -1385,8 +1408,14 @@ int i915_vma_pin_ww(struct i915_vma *vma
+       if (err)
+               return err;
+-      if (flags & PIN_GLOBAL)
+-              wakeref = intel_runtime_pm_get(&vma->vm->i915->runtime_pm);
++      /*
++       * In case of a global GTT, we must hold a runtime-pm wakeref
++       * while global PTEs are updated.  In other cases, we hold
++       * the rpm reference while the VMA is active.  Since runtime
++       * resume may require allocations, which are forbidden inside
++       * vm->mutex, get the first rpm wakeref outside of the mutex.
++       */
++      wakeref = intel_runtime_pm_get(&vma->vm->i915->runtime_pm);
+       if (flags & vma->vm->bind_async_flags) {
+               /* lock VM */
+@@ -1522,8 +1551,7 @@ err_fence:
+       if (work)
+               dma_fence_work_commit_imm(&work->base);
+ err_rpm:
+-      if (wakeref)
+-              intel_runtime_pm_put(&vma->vm->i915->runtime_pm, wakeref);
++      intel_runtime_pm_put(&vma->vm->i915->runtime_pm, wakeref);
+       if (moving)
+               dma_fence_put(moving);
diff --git a/queue-6.1/net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch b/queue-6.1/net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch
new file mode 100644 (file)
index 0000000..f8cb7c9
--- /dev/null
@@ -0,0 +1,64 @@
+From 56f78615bcb1c3ba58a5d9911bad3d9185cf141b Mon Sep 17 00:00:00 2001
+From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+Date: Wed, 17 Apr 2024 10:55:13 +0200
+Subject: net: usb: ax88179_178a: avoid writing the mac address before first reading
+
+From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+
+commit 56f78615bcb1c3ba58a5d9911bad3d9185cf141b upstream.
+
+After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
+consecutive device resets"), reset operation, in which the default mac
+address from the device is read, is not executed from bind operation and
+the random address, that is pregenerated just in case, is direclty written
+the first time in the device, so the default one from the device is not
+even read. This writing is not dangerous because is volatile and the
+default mac address is not missed.
+
+In order to avoid this and keep the simplification to have only one
+reset and reduce the delays, restore the reset from bind operation and
+remove the reset that is commanded from open operation. The behavior is
+the same but everything is ready for usbnet_probe.
+
+Tested with ASIX AX88179 USB Gigabit Ethernet devices.
+Restore the old behavior for the rest of possible devices because I don't
+have the hardware to test.
+
+cc: stable@vger.kernel.org # 6.6+
+Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets")
+Reported-by: Jarkko Palviainen <jarkko.palviainen@gmail.com>
+Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+Link: https://lore.kernel.org/r/20240417085524.219532-1-jtornosm@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/ax88179_178a.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/usb/ax88179_178a.c
++++ b/drivers/net/usb/ax88179_178a.c
+@@ -1317,6 +1317,8 @@ static int ax88179_bind(struct usbnet *d
+       netif_set_tso_max_size(dev->net, 16384);
++      ax88179_reset(dev);
++
+       return 0;
+ }
+@@ -1695,7 +1697,6 @@ static const struct driver_info ax88179_
+       .unbind = ax88179_unbind,
+       .status = ax88179_status,
+       .link_reset = ax88179_link_reset,
+-      .reset = ax88179_reset,
+       .stop = ax88179_stop,
+       .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+       .rx_fixup = ax88179_rx_fixup,
+@@ -1708,7 +1709,6 @@ static const struct driver_info ax88178a
+       .unbind = ax88179_unbind,
+       .status = ax88179_status,
+       .link_reset = ax88179_link_reset,
+-      .reset = ax88179_reset,
+       .stop = ax88179_stop,
+       .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+       .rx_fixup = ax88179_rx_fixup,
diff --git a/queue-6.1/random-handle-creditable-entropy-from-atomic-process-context.patch b/queue-6.1/random-handle-creditable-entropy-from-atomic-process-context.patch
new file mode 100644 (file)
index 0000000..c03ea12
--- /dev/null
@@ -0,0 +1,94 @@
+From e871abcda3b67d0820b4182ebe93435624e9c6a4 Mon Sep 17 00:00:00 2001
+From: "Jason A. Donenfeld" <Jason@zx2c4.com>
+Date: Wed, 17 Apr 2024 13:38:29 +0200
+Subject: random: handle creditable entropy from atomic process context
+
+From: Jason A. Donenfeld <Jason@zx2c4.com>
+
+commit e871abcda3b67d0820b4182ebe93435624e9c6a4 upstream.
+
+The entropy accounting changes a static key when the RNG has
+initialized, since it only ever initializes once. Static key changes,
+however, cannot be made from atomic context, so depending on where the
+last creditable entropy comes from, the static key change might need to
+be deferred to a worker.
+
+Previously the code used the execute_in_process_context() helper
+function, which accounts for whether or not the caller is
+in_interrupt(). However, that doesn't account for the case where the
+caller is actually in process context but is holding a spinlock.
+
+This turned out to be the case with input_handle_event() in
+drivers/input/input.c contributing entropy:
+
+  [<ffffffd613025ba0>] die+0xa8/0x2fc
+  [<ffffffd613027428>] bug_handler+0x44/0xec
+  [<ffffffd613016964>] brk_handler+0x90/0x144
+  [<ffffffd613041e58>] do_debug_exception+0xa0/0x148
+  [<ffffffd61400c208>] el1_dbg+0x60/0x7c
+  [<ffffffd61400c000>] el1h_64_sync_handler+0x38/0x90
+  [<ffffffd613011294>] el1h_64_sync+0x64/0x6c
+  [<ffffffd613102d88>] __might_resched+0x1fc/0x2e8
+  [<ffffffd613102b54>] __might_sleep+0x44/0x7c
+  [<ffffffd6130b6eac>] cpus_read_lock+0x1c/0xec
+  [<ffffffd6132c2820>] static_key_enable+0x14/0x38
+  [<ffffffd61400ac08>] crng_set_ready+0x14/0x28
+  [<ffffffd6130df4dc>] execute_in_process_context+0xb8/0xf8
+  [<ffffffd61400ab30>] _credit_init_bits+0x118/0x1dc
+  [<ffffffd6138580c8>] add_timer_randomness+0x264/0x270
+  [<ffffffd613857e54>] add_input_randomness+0x38/0x48
+  [<ffffffd613a80f94>] input_handle_event+0x2b8/0x490
+  [<ffffffd613a81310>] input_event+0x6c/0x98
+
+According to Guoyong, it's not really possible to refactor the various
+drivers to never hold a spinlock there. And in_atomic() isn't reliable.
+
+So, rather than trying to be too fancy, just punt the change in the
+static key to a workqueue always. There's basically no drawback of doing
+this, as the code already needed to account for the static key not
+changing immediately, and given that it's just an optimization, there's
+not exactly a hurry to change the static key right away, so deferal is
+fine.
+
+Reported-by: Guoyong Wang <guoyong.wang@mediatek.com>
+Cc: stable@vger.kernel.org
+Fixes: f5bda35fba61 ("random: use static branch for crng_ready()")
+Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/random.c |   10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/char/random.c
++++ b/drivers/char/random.c
+@@ -683,7 +683,7 @@ static void extract_entropy(void *buf, s
+ static void __cold _credit_init_bits(size_t bits)
+ {
+-      static struct execute_work set_ready;
++      static DECLARE_WORK(set_ready, crng_set_ready);
+       unsigned int new, orig, add;
+       unsigned long flags;
+@@ -699,8 +699,8 @@ static void __cold _credit_init_bits(siz
+       if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) {
+               crng_reseed(); /* Sets crng_init to CRNG_READY under base_crng.lock. */
+-              if (static_key_initialized)
+-                      execute_in_process_context(crng_set_ready, &set_ready);
++              if (static_key_initialized && system_unbound_wq)
++                      queue_work(system_unbound_wq, &set_ready);
+               wake_up_interruptible(&crng_init_wait);
+               kill_fasync(&fasync, SIGIO, POLL_IN);
+               pr_notice("crng init done\n");
+@@ -870,8 +870,8 @@ void __init random_init(void)
+       /*
+        * If we were initialized by the cpu or bootloader before jump labels
+-       * are initialized, then we should enable the static branch here, where
+-       * it's guaranteed that jump labels have been initialized.
++       * or workqueues are initialized, then we should enable the static
++       * branch here, where it's guaranteed that these have been initialized.
+        */
+       if (!static_branch_likely(&crng_is_ready) && crng_init >= CRNG_READY)
+               crng_set_ready(NULL);
diff --git a/queue-6.1/selftests-ftrace-limit-length-in-subsystem-enable-tests.patch b/queue-6.1/selftests-ftrace-limit-length-in-subsystem-enable-tests.patch
new file mode 100644 (file)
index 0000000..550d5e4
--- /dev/null
@@ -0,0 +1,55 @@
+From 1a4ea83a6e67f1415a1f17c1af5e9c814c882bb5 Mon Sep 17 00:00:00 2001
+From: Yuanhe Shu <xiangzao@linux.alibaba.com>
+Date: Mon, 26 Feb 2024 11:18:16 +0800
+Subject: selftests/ftrace: Limit length in subsystem-enable tests
+
+From: Yuanhe Shu <xiangzao@linux.alibaba.com>
+
+commit 1a4ea83a6e67f1415a1f17c1af5e9c814c882bb5 upstream.
+
+While sched* events being traced and sched* events continuously happen,
+"[xx] event tracing - enable/disable with subsystem level files" would
+not stop as on some slower systems it seems to take forever.
+Select the first 100 lines of output would be enough to judge whether
+there are more than 3 types of sched events.
+
+Fixes: 815b18ea66d6 ("ftracetest: Add basic event tracing test cases")
+Cc: stable@vger.kernel.org
+Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
++++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
+@@ -18,7 +18,7 @@ echo 'sched:*' > set_event
+ yield
+-count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
++count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
+ if [ $count -lt 3 ]; then
+     fail "at least fork, exec and exit events should be recorded"
+ fi
+@@ -29,7 +29,7 @@ echo 1 > events/sched/enable
+ yield
+-count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
++count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
+ if [ $count -lt 3 ]; then
+     fail "at least fork, exec and exit events should be recorded"
+ fi
+@@ -40,7 +40,7 @@ echo 0 > events/sched/enable
+ yield
+-count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
++count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
+ if [ $count -ne 0 ]; then
+     fail "any of scheduler events should not be recorded"
+ fi
index 561c5e301d36a6ebe3c83d1e3d1a649b49572a56..3f1d8f78dc016c933aeb05d4e5a809222e228fb6 100644 (file)
@@ -3,3 +3,8 @@ drm-amdgpu-fix-incorrect-active-rb-bitmap-for-gfx11.patch
 drm-amdgpu-fix-incorrect-number-of-active-rbs-for-gf.patch
 drm-amd-display-do-not-recursively-call-manual-trigg.patch
 io_uring-fix-io_cqring_wait-not-restoring-sigmask-on-get_timespec64-failure.patch
+sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch
+selftests-ftrace-limit-length-in-subsystem-enable-tests.patch
+random-handle-creditable-entropy-from-atomic-process-context.patch
+net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch
+drm-i915-vma-fix-uaf-on-destroy-against-retire-race.patch
diff --git a/queue-6.1/sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch b/queue-6.1/sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch
new file mode 100644 (file)
index 0000000..a0fa8de
--- /dev/null
@@ -0,0 +1,54 @@
+From a4833e3abae132d613ce7da0e0c9a9465d1681fa Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Wed, 10 Apr 2024 12:38:13 -0400
+Subject: SUNRPC: Fix rpcgss_context trace event acceptor field
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit a4833e3abae132d613ce7da0e0c9a9465d1681fa upstream.
+
+The rpcgss_context trace event acceptor field is a dynamically sized
+string that records the "data" parameter. But this parameter is also
+dependent on the "len" field to determine the size of the data.
+
+It needs to use __string_len() helper macro where the length can be passed
+in. It also incorrectly uses strncpy() to save it instead of
+__assign_str(). As these macros can change, it is not wise to open code
+them in trace events.
+
+As of commit c759e609030c ("tracing: Remove __assign_str_len()"),
+__assign_str() can be used for both __string() and __string_len() fields.
+Before that commit, __assign_str_len() is required to be used. This needs
+to be noted for backporting. (In actuality, commit c1fa617caeb0 ("tracing:
+Rework __assign_str() and __string() to not duplicate getting the string")
+is the commit that makes __string_str_len() obsolete).
+
+Cc: stable@vger.kernel.org
+Fixes: 0c77668ddb4e ("SUNRPC: Introduce trace points in rpc_auth_gss.ko")
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/trace/events/rpcgss.h |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/trace/events/rpcgss.h
++++ b/include/trace/events/rpcgss.h
+@@ -587,7 +587,7 @@ TRACE_EVENT(rpcgss_context,
+               __field(unsigned int, timeout)
+               __field(u32, window_size)
+               __field(int, len)
+-              __string(acceptor, data)
++              __string_len(acceptor, data, len)
+       ),
+       TP_fast_assign(
+@@ -596,7 +596,7 @@ TRACE_EVENT(rpcgss_context,
+               __entry->timeout = timeout;
+               __entry->window_size = window_size;
+               __entry->len = len;
+-              strncpy(__get_str(acceptor), data, len);
++              __assign_str(acceptor, data);
+       ),
+       TP_printk("win_size=%u expiry=%lu now=%lu timeout=%u acceptor=%.*s",