--- /dev/null
+From a543ada7db729514ddd3ba4efa45f4c7b802ad85 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
+Date: Mon, 13 Mar 2023 10:17:24 +0100
+Subject: crypto: api - Demote BUG_ON() in crypto_unregister_alg() to a WARN_ON()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Toke Høiland-Jørgensen <toke@redhat.com>
+
+commit a543ada7db729514ddd3ba4efa45f4c7b802ad85 upstream.
+
+The crypto_unregister_alg() function expects callers to ensure that any
+algorithm that is unregistered has a refcnt of exactly 1, and issues a
+BUG_ON() if this is not the case. However, there are in fact drivers that
+will call crypto_unregister_alg() without ensuring that the refcnt has been
+lowered first, most notably on system shutdown. This causes the BUG_ON() to
+trigger, which prevents a clean shutdown and hangs the system.
+
+To avoid such hangs on shutdown, demote the BUG_ON() in
+crypto_unregister_alg() to a WARN_ON() with early return. Cc stable because
+this problem was observed on a 6.2 kernel, cf the link below.
+
+Link: https://lore.kernel.org/r/87r0tyq8ph.fsf@toke.dk
+Cc: stable@vger.kernel.org
+Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/algapi.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/crypto/algapi.c
++++ b/crypto/algapi.c
+@@ -456,7 +456,9 @@ void crypto_unregister_alg(struct crypto
+ if (WARN(ret, "Algorithm %s is not registered", alg->cra_driver_name))
+ return;
+
+- BUG_ON(refcount_read(&alg->cra_refcnt) != 1);
++ if (WARN_ON(refcount_read(&alg->cra_refcnt) != 1))
++ return;
++
+ if (alg->cra_destroy)
+ alg->cra_destroy(alg);
+
--- /dev/null
+From ca25c00ccbc5f942c63897ed23584cfc66e8ec81 Mon Sep 17 00:00:00 2001
+From: Jonathan McDowell <noodles@earth.li>
+Date: Tue, 28 Feb 2023 18:28:58 +0000
+Subject: crypto: safexcel - Cleanup ring IRQ workqueues on load failure
+
+From: Jonathan McDowell <noodles@earth.li>
+
+commit ca25c00ccbc5f942c63897ed23584cfc66e8ec81 upstream.
+
+A failure loading the safexcel driver results in the following warning
+on boot, because the IRQ affinity has not been correctly cleaned up.
+Ensure we clean up the affinity and workqueues on a failure to load the
+driver.
+
+crypto-safexcel: probe of f2800000.crypto failed with error -2
+------------[ cut here ]------------
+WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340
+Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4
+CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G W 6.1.6-00002-g9d4898824677 #3
+Hardware name: MikroTik RB5009 (DT)
+pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : free_irq+0x300/0x340
+lr : free_irq+0x2e0/0x340
+sp : ffff800008fa3890
+x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000
+x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50
+x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80
+x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000
+x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5e
+x14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040
+x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370
+x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18
+x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188
+x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0
+Call trace:
+ free_irq+0x300/0x340
+ devm_irq_release+0x14/0x20
+ devres_release_all+0xa0/0x100
+ device_unbind_cleanup+0x14/0x60
+ really_probe+0x198/0x2d4
+ __driver_probe_device+0x74/0xdc
+ driver_probe_device+0x3c/0x110
+ __driver_attach+0x8c/0x190
+ bus_for_each_dev+0x6c/0xc0
+ driver_attach+0x20/0x30
+ bus_add_driver+0x148/0x1fc
+ driver_register+0x74/0x120
+ __platform_driver_register+0x24/0x30
+ safexcel_init+0x48/0x1000 [crypto_safexcel]
+ do_one_initcall+0x4c/0x1b0
+ do_init_module+0x44/0x1cc
+ load_module+0x1724/0x1be4
+ __do_sys_finit_module+0xbc/0x110
+ __arm64_sys_finit_module+0x1c/0x24
+ invoke_syscall+0x44/0x110
+ el0_svc_common.constprop.0+0xc0/0xe0
+ do_el0_svc+0x20/0x80
+ el0_svc+0x14/0x4c
+ el0t_64_sync_handler+0xb0/0xb4
+ el0t_64_sync+0x148/0x14c
+---[ end trace 0000000000000000 ]---
+
+Fixes: 1b44c5a60c13 ("inside-secure - add SafeXcel EIP197 crypto engine driver")
+Signed-off-by: Jonathan McDowell <noodles@earth.li>
+Cc: stable@vger.kernel.org
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/inside-secure/safexcel.c | 37 +++++++++++++++++++++++---------
+ 1 file changed, 27 insertions(+), 10 deletions(-)
+
+--- a/drivers/crypto/inside-secure/safexcel.c
++++ b/drivers/crypto/inside-secure/safexcel.c
+@@ -1634,19 +1634,23 @@ static int safexcel_probe_generic(void *
+ &priv->ring[i].rdr);
+ if (ret) {
+ dev_err(dev, "Failed to initialize rings\n");
+- return ret;
++ goto err_cleanup_rings;
+ }
+
+ priv->ring[i].rdr_req = devm_kcalloc(dev,
+ EIP197_DEFAULT_RING_SIZE,
+ sizeof(*priv->ring[i].rdr_req),
+ GFP_KERNEL);
+- if (!priv->ring[i].rdr_req)
+- return -ENOMEM;
++ if (!priv->ring[i].rdr_req) {
++ ret = -ENOMEM;
++ goto err_cleanup_rings;
++ }
+
+ ring_irq = devm_kzalloc(dev, sizeof(*ring_irq), GFP_KERNEL);
+- if (!ring_irq)
+- return -ENOMEM;
++ if (!ring_irq) {
++ ret = -ENOMEM;
++ goto err_cleanup_rings;
++ }
+
+ ring_irq->priv = priv;
+ ring_irq->ring = i;
+@@ -1660,7 +1664,8 @@ static int safexcel_probe_generic(void *
+ ring_irq);
+ if (irq < 0) {
+ dev_err(dev, "Failed to get IRQ ID for ring %d\n", i);
+- return irq;
++ ret = irq;
++ goto err_cleanup_rings;
+ }
+
+ priv->ring[i].irq = irq;
+@@ -1672,8 +1677,10 @@ static int safexcel_probe_generic(void *
+ snprintf(wq_name, 9, "wq_ring%d", i);
+ priv->ring[i].workqueue =
+ create_singlethread_workqueue(wq_name);
+- if (!priv->ring[i].workqueue)
+- return -ENOMEM;
++ if (!priv->ring[i].workqueue) {
++ ret = -ENOMEM;
++ goto err_cleanup_rings;
++ }
+
+ priv->ring[i].requests = 0;
+ priv->ring[i].busy = false;
+@@ -1690,16 +1697,26 @@ static int safexcel_probe_generic(void *
+ ret = safexcel_hw_init(priv);
+ if (ret) {
+ dev_err(dev, "HW init failed (%d)\n", ret);
+- return ret;
++ goto err_cleanup_rings;
+ }
+
+ ret = safexcel_register_algorithms(priv);
+ if (ret) {
+ dev_err(dev, "Failed to register algorithms (%d)\n", ret);
+- return ret;
++ goto err_cleanup_rings;
+ }
+
+ return 0;
++
++err_cleanup_rings:
++ for (i = 0; i < priv->config.rings; i++) {
++ if (priv->ring[i].irq)
++ irq_set_affinity_hint(priv->ring[i].irq, NULL);
++ if (priv->ring[i].workqueue)
++ destroy_workqueue(priv->ring[i].workqueue);
++ }
++
++ return ret;
+ }
+
+ static void safexcel_hw_reset_rings(struct safexcel_crypto_priv *priv)
--- /dev/null
+From 4984563823f0034d3533854c1b50e729f5191089 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 4 Apr 2023 17:23:59 -0700
+Subject: KVM: nVMX: Emulate NOPs in L2, and PAUSE if it's not intercepted
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 4984563823f0034d3533854c1b50e729f5191089 upstream.
+
+Extend VMX's nested intercept logic for emulated instructions to handle
+"pause" interception, in quotes because KVM's emulator doesn't filter out
+NOPs when checking for nested intercepts. Failure to allow emulation of
+NOPs results in KVM injecting a #UD into L2 on any NOP that collides with
+the emulator's definition of PAUSE, i.e. on all single-byte NOPs.
+
+For PAUSE itself, honor L1's PAUSE-exiting control, but ignore PLE to
+avoid unnecessarily injecting a #UD into L2. Per the SDM, the first
+execution of PAUSE after VM-Entry is treated as the beginning of a new
+loop, i.e. will never trigger a PLE VM-Exit, and so L1 can't expect any
+given execution of PAUSE to deterministically exit.
+
+ ... the processor considers this execution to be the first execution of
+ PAUSE in a loop. (It also does so for the first execution of PAUSE at
+ CPL 0 after VM entry.)
+
+All that said, the PLE side of things is currently a moot point, as KVM
+doesn't expose PLE to L1.
+
+Note, vmx_check_intercept() is still wildly broken when L1 wants to
+intercept an instruction, as KVM injects a #UD instead of synthesizing a
+nested VM-Exit. That issue extends far beyond NOP/PAUSE and needs far
+more effort to fix, i.e. is a problem for the future.
+
+Fixes: 07721feee46b ("KVM: nVMX: Don't emulate instructions in guest mode")
+Cc: Mathias Krause <minipli@grsecurity.net>
+Cc: stable@vger.kernel.org
+Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
+Link: https://lore.kernel.org/r/20230405002359.418138-1-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/vmx.c | 15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -7536,6 +7536,21 @@ static int vmx_check_intercept(struct kv
+ /* FIXME: produce nested vmexit and return X86EMUL_INTERCEPTED. */
+ break;
+
++ case x86_intercept_pause:
++ /*
++ * PAUSE is a single-byte NOP with a REPE prefix, i.e. collides
++ * with vanilla NOPs in the emulator. Apply the interception
++ * check only to actual PAUSE instructions. Don't check
++ * PAUSE-loop-exiting, software can't expect a given PAUSE to
++ * exit, i.e. KVM is within its rights to allow L2 to execute
++ * the PAUSE.
++ */
++ if ((info->rep_prefix != REPE_PREFIX) ||
++ !nested_cpu_has2(vmcs12, CPU_BASED_PAUSE_EXITING))
++ return X86EMUL_CONTINUE;
++
++ break;
++
+ /* TODO: check more intercepts... */
+ default:
+ break;
--- /dev/null
+From eb411c0cf59ae6344b34bc6f0d298a22b300627e Mon Sep 17 00:00:00 2001
+From: Heiner Kallweit <hkallweit1@gmail.com>
+Date: Sun, 9 Apr 2023 17:15:52 +0200
+Subject: pwm: meson: Fix axg ao mux parents
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+commit eb411c0cf59ae6344b34bc6f0d298a22b300627e upstream.
+
+This fix is basically the same as 9bce02ef0dfa ("pwm: meson: Fix the
+G12A AO clock parents order"). Vendor driver referenced there has
+xtal as first parent also for axg ao. In addition fix the name
+of the aoclk81 clock. Apparently name aoclk81 as used by the vendor
+driver was changed when mainlining the axg clock driver.
+
+Fixes: bccaa3f917c9 ("pwm: meson: Add clock source configuration for Meson-AXG")
+Cc: stable@vger.kernel.org
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pwm/pwm-meson.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pwm/pwm-meson.c
++++ b/drivers/pwm/pwm-meson.c
+@@ -424,7 +424,7 @@ static const struct meson_pwm_data pwm_a
+ };
+
+ static const char * const pwm_axg_ao_parent_names[] = {
+- "aoclk81", "xtal", "fclk_div4", "fclk_div5"
++ "xtal", "axg_ao_clk81", "fclk_div4", "fclk_div5"
+ };
+
+ static const struct meson_pwm_data pwm_axg_ao_data = {
--- /dev/null
+From 9e4fa80ab7ef9eb4f7b1ea9fc31e0eb040e85e25 Mon Sep 17 00:00:00 2001
+From: Heiner Kallweit <hkallweit1@gmail.com>
+Date: Tue, 11 Apr 2023 07:34:11 +0200
+Subject: pwm: meson: Fix g12a ao clk81 name
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+commit 9e4fa80ab7ef9eb4f7b1ea9fc31e0eb040e85e25 upstream.
+
+Fix the name of the aoclk81 clock. Apparently name aoclk81 as used by
+the vendor driver was changed when mainlining the g12a clock driver.
+
+Fixes: f41efceb46e6 ("pwm: meson: Add clock source configuration for Meson G12A")
+Cc: stable@vger.kernel.org
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pwm/pwm-meson.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/pwm/pwm-meson.c
++++ b/drivers/pwm/pwm-meson.c
+@@ -433,7 +433,7 @@ static const struct meson_pwm_data pwm_a
+ };
+
+ static const char * const pwm_g12a_ao_ab_parent_names[] = {
+- "xtal", "aoclk81", "fclk_div4", "fclk_div5"
++ "xtal", "g12a_ao_clk81", "fclk_div4", "fclk_div5"
+ };
+
+ static const struct meson_pwm_data pwm_g12a_ao_ab_data = {
+@@ -442,7 +442,7 @@ static const struct meson_pwm_data pwm_g
+ };
+
+ static const char * const pwm_g12a_ao_cd_parent_names[] = {
+- "xtal", "aoclk81",
++ "xtal", "g12a_ao_clk81",
+ };
+
+ static const struct meson_pwm_data pwm_g12a_ao_cd_data = {
--- /dev/null
+From 7a29fb4a4771124bc61de397dbfc1554dbbcc19c Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Fri, 6 Jan 2023 15:09:34 +0800
+Subject: rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit 7a29fb4a4771124bc61de397dbfc1554dbbcc19c upstream.
+
+Registering a kprobe on __rcu_irq_enter_check_tick() can cause kernel
+stack overflow as shown below. This issue can be reproduced by enabling
+CONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=",
+and then giving the following commands at the shell prompt:
+
+ # cd /sys/kernel/tracing/
+ # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events
+ # echo 1 > events/kprobes/enable
+
+This commit therefore adds __rcu_irq_enter_check_tick() to the kprobes
+blacklist using NOKPROBE_SYMBOL().
+
+Insufficient stack space to handle exception!
+ESR: 0x00000000f2000004 -- BRK (AArch64)
+FAR: 0x0000ffffccf3e510
+Task stack: [0xffff80000ad30000..0xffff80000ad38000]
+IRQ stack: [0xffff800008050000..0xffff800008058000]
+Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310]
+CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19
+Hardware name: linux,dummy-virt (DT)
+pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : __rcu_irq_enter_check_tick+0x0/0x1b8
+lr : ct_nmi_enter+0x11c/0x138
+sp : ffff80000ad30080
+x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000
+x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000
+x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148
+x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000
+x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c
+x14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809
+x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000
+x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001
+x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4
+x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000
+Kernel panic - not syncing: kernel stack overflow
+CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19
+Hardware name: linux,dummy-virt (DT)
+Call trace:
+ dump_backtrace+0xf8/0x108
+ show_stack+0x20/0x30
+ dump_stack_lvl+0x68/0x84
+ dump_stack+0x1c/0x38
+ panic+0x214/0x404
+ add_taint+0x0/0xf8
+ panic_bad_stack+0x144/0x160
+ handle_bad_stack+0x38/0x58
+ __bad_stack+0x78/0x7c
+ __rcu_irq_enter_check_tick+0x0/0x1b8
+ arm64_enter_el1_dbg.isra.0+0x14/0x20
+ el1_dbg+0x2c/0x90
+ el1h_64_sync_handler+0xcc/0xe8
+ el1h_64_sync+0x64/0x68
+ __rcu_irq_enter_check_tick+0x0/0x1b8
+ arm64_enter_el1_dbg.isra.0+0x14/0x20
+ el1_dbg+0x2c/0x90
+ el1h_64_sync_handler+0xcc/0xe8
+ el1h_64_sync+0x64/0x68
+ __rcu_irq_enter_check_tick+0x0/0x1b8
+ arm64_enter_el1_dbg.isra.0+0x14/0x20
+ el1_dbg+0x2c/0x90
+ el1h_64_sync_handler+0xcc/0xe8
+ el1h_64_sync+0x64/0x68
+ __rcu_irq_enter_check_tick+0x0/0x1b8
+ [...]
+ el1_dbg+0x2c/0x90
+ el1h_64_sync_handler+0xcc/0xe8
+ el1h_64_sync+0x64/0x68
+ __rcu_irq_enter_check_tick+0x0/0x1b8
+ arm64_enter_el1_dbg.isra.0+0x14/0x20
+ el1_dbg+0x2c/0x90
+ el1h_64_sync_handler+0xcc/0xe8
+ el1h_64_sync+0x64/0x68
+ __rcu_irq_enter_check_tick+0x0/0x1b8
+ arm64_enter_el1_dbg.isra.0+0x14/0x20
+ el1_dbg+0x2c/0x90
+ el1h_64_sync_handler+0xcc/0xe8
+ el1h_64_sync+0x64/0x68
+ __rcu_irq_enter_check_tick+0x0/0x1b8
+ el1_interrupt+0x28/0x60
+ el1h_64_irq_handler+0x18/0x28
+ el1h_64_irq+0x64/0x68
+ __ftrace_set_clr_event_nolock+0x98/0x198
+ __ftrace_set_clr_event+0x58/0x80
+ system_enable_write+0x144/0x178
+ vfs_write+0x174/0x738
+ ksys_write+0xd0/0x188
+ __arm64_sys_write+0x4c/0x60
+ invoke_syscall+0x64/0x180
+ el0_svc_common.constprop.0+0x84/0x160
+ do_el0_svc+0x48/0xe8
+ el0_svc+0x34/0xd0
+ el0t_64_sync_handler+0xb8/0xc0
+ el0t_64_sync+0x190/0x194
+SMP: stopping secondary CPUs
+Kernel Offset: 0x28da86000000 from 0xffff800008000000
+PHYS_OFFSET: 0xfffff76600000000
+CPU features: 0x00000,01a00100,0000421b
+Memory Limit: none
+
+Acked-by: Joel Fernandes (Google) <joel@joelfernandes.org>
+Link: https://lore.kernel.org/all/20221119040049.795065-1-zhengyejian1@huawei.com/
+Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from rcu_nmi_enter()")
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/rcu/tree.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/kernel/rcu/tree.c
++++ b/kernel/rcu/tree.c
+@@ -964,6 +964,7 @@ void __rcu_irq_enter_check_tick(void)
+ }
+ raw_spin_unlock_rcu_node(rdp->mynode);
+ }
++NOKPROBE_SYMBOL(__rcu_irq_enter_check_tick);
+ #endif /* CONFIG_NO_HZ_FULL */
+
+ /**
--- /dev/null
+From d82dcd9e21b77d338dc4875f3d4111f0db314a7c Mon Sep 17 00:00:00 2001
+From: Roberto Sassu <roberto.sassu@huawei.com>
+Date: Fri, 31 Mar 2023 14:32:18 +0200
+Subject: reiserfs: Add security prefix to xattr name in reiserfs_security_write()
+
+From: Roberto Sassu <roberto.sassu@huawei.com>
+
+commit d82dcd9e21b77d338dc4875f3d4111f0db314a7c upstream.
+
+Reiserfs sets a security xattr at inode creation time in two stages: first,
+it calls reiserfs_security_init() to obtain the xattr from active LSMs;
+then, it calls reiserfs_security_write() to actually write that xattr.
+
+Unfortunately, it seems there is a wrong expectation that LSMs provide the
+full xattr name in the form 'security.<suffix>'. However, LSMs always
+provided just the suffix, causing reiserfs to not write the xattr at all
+(if the suffix is shorter than the prefix), or to write an xattr with the
+wrong name.
+
+Add a temporary buffer in reiserfs_security_write(), and write to it the
+full xattr name, before passing it to reiserfs_xattr_set_handle().
+
+Also replace the name length check with a check that the full xattr name is
+not larger than XATTR_NAME_MAX.
+
+Cc: stable@vger.kernel.org # v2.6.x
+Fixes: 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation")
+Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/reiserfs/xattr_security.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/fs/reiserfs/xattr_security.c
++++ b/fs/reiserfs/xattr_security.c
+@@ -81,11 +81,15 @@ int reiserfs_security_write(struct reise
+ struct inode *inode,
+ struct reiserfs_security_handle *sec)
+ {
++ char xattr_name[XATTR_NAME_MAX + 1] = XATTR_SECURITY_PREFIX;
+ int error;
+- if (strlen(sec->name) < sizeof(XATTR_SECURITY_PREFIX))
++
++ if (XATTR_SECURITY_PREFIX_LEN + strlen(sec->name) > XATTR_NAME_MAX)
+ return -EINVAL;
+
+- error = reiserfs_xattr_set_handle(th, inode, sec->name, sec->value,
++ strlcat(xattr_name, sec->name, sizeof(xattr_name));
++
++ error = reiserfs_xattr_set_handle(th, inode, xattr_name, sec->value,
+ sec->length, XATTR_CREATE);
+ if (error == -ENODATA || error == -EOPNOTSUPP)
+ error = 0;
--- /dev/null
+From 43ec16f1450f4936025a9bdf1a273affdb9732c1 Mon Sep 17 00:00:00 2001
+From: Zhang Zhengming <zhang.zhengming@h3c.com>
+Date: Wed, 19 Apr 2023 12:02:03 +0800
+Subject: relayfs: fix out-of-bounds access in relay_file_read
+
+From: Zhang Zhengming <zhang.zhengming@h3c.com>
+
+commit 43ec16f1450f4936025a9bdf1a273affdb9732c1 upstream.
+
+There is a crash in relay_file_read, as the var from
+point to the end of last subbuf.
+
+The oops looks something like:
+pc : __arch_copy_to_user+0x180/0x310
+lr : relay_file_read+0x20c/0x2c8
+Call trace:
+ __arch_copy_to_user+0x180/0x310
+ full_proxy_read+0x68/0x98
+ vfs_read+0xb0/0x1d0
+ ksys_read+0x6c/0xf0
+ __arm64_sys_read+0x20/0x28
+ el0_svc_common.constprop.3+0x84/0x108
+ do_el0_svc+0x74/0x90
+ el0_svc+0x1c/0x28
+ el0_sync_handler+0x88/0xb0
+ el0_sync+0x148/0x180
+
+We get the condition by analyzing the vmcore:
+
+1). The last produced byte and last consumed byte
+ both at the end of the last subbuf
+
+2). A softirq calls function(e.g __blk_add_trace)
+ to write relay buffer occurs when an program is calling
+ relay_file_read_avail().
+
+ relay_file_read
+ relay_file_read_avail
+ relay_file_read_consume(buf, 0, 0);
+ //interrupted by softirq who will write subbuf
+ ....
+ return 1;
+ //read_start point to the end of the last subbuf
+ read_start = relay_file_read_start_pos
+ //avail is equal to subsize
+ avail = relay_file_read_subbuf_avail
+ //from points to an invalid memory address
+ from = buf->start + read_start
+ //system is crashed
+ copy_to_user(buffer, from, avail)
+
+Link: https://lkml.kernel.org/r/20230419040203.37676-1-zhang.zhengming@h3c.com
+Fixes: 8d62fdebdaf9 ("relay file read: start-pos fix")
+Signed-off-by: Zhang Zhengming <zhang.zhengming@h3c.com>
+Reviewed-by: Zhao Lei <zhao_lei1@hoperun.com>
+Reviewed-by: Zhou Kete <zhou.kete@h3c.com>
+Reviewed-by: Pengcheng Yang <yangpc@wangsu.com>
+Cc: Jens Axboe <axboe@kernel.dk>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/relay.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/relay.c
++++ b/kernel/relay.c
+@@ -1077,7 +1077,8 @@ static size_t relay_file_read_start_pos(
+ size_t subbuf_size = buf->chan->subbuf_size;
+ size_t n_subbufs = buf->chan->n_subbufs;
+ size_t consumed = buf->subbufs_consumed % n_subbufs;
+- size_t read_pos = consumed * subbuf_size + buf->bytes_consumed;
++ size_t read_pos = (consumed * subbuf_size + buf->bytes_consumed)
++ % (n_subbufs * subbuf_size);
+
+ read_subbuf = read_pos / subbuf_size;
+ padding = buf->padding[read_subbuf];
--- /dev/null
+From 675751bb20634f981498c7d66161584080cc061e Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Thu, 27 Apr 2023 17:59:20 +0200
+Subject: ring-buffer: Sync IRQ works before buffer destruction
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 675751bb20634f981498c7d66161584080cc061e upstream.
+
+If something was written to the buffer just before destruction,
+it may be possible (maybe not in a real system, but it did
+happen in ARCH=um with time-travel) to destroy the ringbuffer
+before the IRQ work ran, leading this KASAN report (or a crash
+without KASAN):
+
+ BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a
+ Read of size 8 at addr 000000006d640a48 by task swapper/0
+
+ CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7
+ Stack:
+ 60c4f20f 0c203d48 41b58ab3 60f224fc
+ 600477fa 60f35687 60c4f20f 601273dd
+ 00000008 6101eb00 6101eab0 615be548
+ Call Trace:
+ [<60047a58>] show_stack+0x25e/0x282
+ [<60c609e0>] dump_stack_lvl+0x96/0xfd
+ [<60c50d4c>] print_report+0x1a7/0x5a8
+ [<603078d3>] kasan_report+0xc1/0xe9
+ [<60308950>] __asan_report_load8_noabort+0x1b/0x1d
+ [<60232844>] irq_work_run_list+0x11a/0x13a
+ [<602328b4>] irq_work_tick+0x24/0x34
+ [<6017f9dc>] update_process_times+0x162/0x196
+ [<6019f335>] tick_sched_handle+0x1a4/0x1c3
+ [<6019fd9e>] tick_sched_timer+0x79/0x10c
+ [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695
+ [<60182913>] hrtimer_interrupt+0x16c/0x2c4
+ [<600486a3>] um_timer+0x164/0x183
+ [...]
+
+ Allocated by task 411:
+ save_stack_trace+0x99/0xb5
+ stack_trace_save+0x81/0x9b
+ kasan_save_stack+0x2d/0x54
+ kasan_set_track+0x34/0x3e
+ kasan_save_alloc_info+0x25/0x28
+ ____kasan_kmalloc+0x8b/0x97
+ __kasan_kmalloc+0x10/0x12
+ __kmalloc+0xb2/0xe8
+ load_elf_phdrs+0xee/0x182
+ [...]
+
+ The buggy address belongs to the object at 000000006d640800
+ which belongs to the cache kmalloc-1k of size 1024
+ The buggy address is located 584 bytes inside of
+ freed 1024-byte region [000000006d640800, 000000006d640c00)
+
+Add the appropriate irq_work_sync() so the work finishes before
+the buffers are destroyed.
+
+Prior to the commit in the Fixes tag below, there was only a
+single global IRQ work, so this issue didn't exist.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20230427175920.a76159263122.I8295e405c44362a86c995e9c2c37e3e03810aa56@changeid
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Fixes: 15693458c4bc ("tracing/ring-buffer: Move poll wake ups into ring buffer code")
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -1644,6 +1644,8 @@ static void rb_free_cpu_buffer(struct ri
+ struct list_head *head = cpu_buffer->pages;
+ struct buffer_page *bpage, *tmp;
+
++ irq_work_sync(&cpu_buffer->irq_work.work);
++
+ free_buffer_page(cpu_buffer->reader_page);
+
+ if (head) {
+@@ -1750,6 +1752,8 @@ ring_buffer_free(struct trace_buffer *bu
+
+ cpuhp_state_remove_instance(CPUHP_TRACE_RB_PREPARE, &buffer->node);
+
++ irq_work_sync(&buffer->irq_work.work);
++
+ for_each_buffer_cpu(buffer, cpu)
+ rb_free_cpu_buffer(buffer->buffers[cpu]);
+
ipmi-ssif-add-send_retries-increment.patch
ipmi-fix-ssif-not-responding-under-certain-cond.patch
kheaders-use-array-declaration-instead-of-char.patch
+pwm-meson-fix-axg-ao-mux-parents.patch
+pwm-meson-fix-g12a-ao-clk81-name.patch
+ring-buffer-sync-irq-works-before-buffer-destruction.patch
+crypto-api-demote-bug_on-in-crypto_unregister_alg-to-a-warn_on.patch
+crypto-safexcel-cleanup-ring-irq-workqueues-on-load-failure.patch
+rcu-avoid-stack-overflow-due-to-__rcu_irq_enter_check_tick-being-kprobe-ed.patch
+reiserfs-add-security-prefix-to-xattr-name-in-reiserfs_security_write.patch
+kvm-nvmx-emulate-nops-in-l2-and-pause-if-it-s-not-intercepted.patch
+relayfs-fix-out-of-bounds-access-in-relay_file_read.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
