--- /dev/null
+From e75a72c77038caa3ae8427942fa2cdfd7302fa89 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 13 Apr 2025 11:11:42 +0100
+Subject: cpufreq: cppc: Fix invalid return value in .get() callback
+
+From: Marc Zyngier <maz@kernel.org>
+
+[ Upstream commit 2b8e6b58889c672e1ae3601d9b2b070be4dc2fbc ]
+
+Returning a negative error code in a function with an unsigned
+return type is a pretty bad idea. It is probably worse when the
+justification for the change is "our static analisys tool found it".
+
+Fixes: cf7de25878a1 ("cppc_cpufreq: Fix possible null pointer dereference")
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: "Rafael J. Wysocki" <rafael@kernel.org>
+Cc: Viresh Kumar <viresh.kumar@linaro.org>
+Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpufreq/cppc_cpufreq.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
+index 17cfa2b92eeec..c5a4aa0c2c9ae 100644
+--- a/drivers/cpufreq/cppc_cpufreq.c
++++ b/drivers/cpufreq/cppc_cpufreq.c
+@@ -620,7 +620,7 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int cpu)
+ int ret;
+
+ if (!policy)
+- return -ENODEV;
++ return 0;
+
+ cpu_data = policy->driver_data;
+
+--
+2.39.5
+
--- /dev/null
+From 1d8a09ff3a223a512a4d82fb4bdcb2f6c54368be Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Apr 2025 23:03:53 +0800
+Subject: cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()
+
+From: Henry Martin <bsdhenrymartin@gmail.com>
+
+[ Upstream commit 484d3f15cc6cbaa52541d6259778e715b2c83c54 ]
+
+cpufreq_cpu_get_raw() can return NULL when the target CPU is not present
+in the policy->cpus mask. scmi_cpufreq_get_rate() does not check for
+this case, which results in a NULL pointer dereference.
+
+Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.
+
+Fixes: 99d6bdf33877 ("cpufreq: add support for CPU DVFS based on SCMI message protocol")
+Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
+Acked-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpufreq/scmi-cpufreq.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
+index eb3f1952f9864..8c9c2f710790f 100644
+--- a/drivers/cpufreq/scmi-cpufreq.c
++++ b/drivers/cpufreq/scmi-cpufreq.c
+@@ -32,11 +32,17 @@ static const struct scmi_perf_proto_ops *perf_ops;
+
+ static unsigned int scmi_cpufreq_get_rate(unsigned int cpu)
+ {
+- struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+- struct scmi_data *priv = policy->driver_data;
++ struct cpufreq_policy *policy;
++ struct scmi_data *priv;
+ unsigned long rate;
+ int ret;
+
++ policy = cpufreq_cpu_get_raw(cpu);
++ if (unlikely(!policy))
++ return 0;
++
++ priv = policy->driver_data;
++
+ ret = perf_ops->freq_get(ph, priv->domain_id, &rate, false);
+ if (ret)
+ return 0;
+--
+2.39.5
+
--- /dev/null
+From 8075f3534bce937104343fd8654295e066f09507 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Apr 2025 23:03:54 +0800
+Subject: cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()
+
+From: Henry Martin <bsdhenrymartin@gmail.com>
+
+[ Upstream commit 73b24dc731731edf762f9454552cb3a5b7224949 ]
+
+cpufreq_cpu_get_raw() can return NULL when the target CPU is not present
+in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for
+this case, which results in a NULL pointer dereference.
+
+Fixes: 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency")
+Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
+Acked-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpufreq/scpi-cpufreq.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
+index 35b20c74dbfc7..f111f1f3bf38d 100644
+--- a/drivers/cpufreq/scpi-cpufreq.c
++++ b/drivers/cpufreq/scpi-cpufreq.c
+@@ -37,9 +37,16 @@ static struct scpi_ops *scpi_ops;
+
+ static unsigned int scpi_cpufreq_get_rate(unsigned int cpu)
+ {
+- struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+- struct scpi_data *priv = policy->driver_data;
+- unsigned long rate = clk_get_rate(priv->clk);
++ struct cpufreq_policy *policy;
++ struct scpi_data *priv;
++ unsigned long rate;
++
++ policy = cpufreq_cpu_get_raw(cpu);
++ if (unlikely(!policy))
++ return 0;
++
++ priv = policy->driver_data;
++ rate = clk_get_rate(priv->clk);
+
+ return rate / 1000;
+ }
+--
+2.39.5
+
--- /dev/null
+From a67981622e3b39e5e98fe76b899b32f0c7344099 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Apr 2025 17:15:42 +0200
+Subject: dma/contiguous: avoid warning about unused size_bytes
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+[ Upstream commit d7b98ae5221007d3f202746903d4c21c7caf7ea9 ]
+
+When building with W=1, this variable is unused for configs with
+CONFIG_CMA_SIZE_SEL_PERCENTAGE=y:
+
+kernel/dma/contiguous.c:67:26: error: 'size_bytes' defined but not used [-Werror=unused-const-variable=]
+
+Change this to a macro to avoid the warning.
+
+Fixes: c64be2bb1c6e ("drivers: add Contiguous Memory Allocator")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Link: https://lore.kernel.org/r/20250409151557.3890443-1-arnd@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/dma/contiguous.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
+index 6ea80ae426228..24d96a2fe0628 100644
+--- a/kernel/dma/contiguous.c
++++ b/kernel/dma/contiguous.c
+@@ -69,8 +69,7 @@ struct cma *dma_contiguous_default_area;
+ * Users, who want to set the size of global CMA area for their system
+ * should use cma= kernel parameter.
+ */
+-static const phys_addr_t size_bytes __initconst =
+- (phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;
++#define size_bytes ((phys_addr_t)CMA_SIZE_MBYTES * SZ_1M)
+ static phys_addr_t size_cmdline __initdata = -1;
+ static phys_addr_t base_cmdline __initdata;
+ static phys_addr_t limit_cmdline __initdata;
+--
+2.39.5
+
--- /dev/null
+From 75240bd6e8eec373ef8adb6d19ba1319ce91966a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Apr 2025 12:38:20 -0700
+Subject: iommu/amd: Return an error if vCPU affinity is set for non-vCPU IRTE
+
+From: Sean Christopherson <seanjc@google.com>
+
+[ Upstream commit 07172206a26dcf3f0bf7c3ecaadd4242b008ea54 ]
+
+Return -EINVAL instead of success if amd_ir_set_vcpu_affinity() is
+invoked without use_vapic; lying to KVM about whether or not the IRTE was
+configured to post IRQs is all kinds of bad.
+
+Fixes: d98de49a53e4 ("iommu/amd: Enable vAPIC interrupt remapping mode by default")
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-ID: <20250404193923.1413163-6-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/amd/iommu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
+index d9251af7f3cf6..7d38cc5c04e68 100644
+--- a/drivers/iommu/amd/iommu.c
++++ b/drivers/iommu/amd/iommu.c
+@@ -3381,7 +3381,7 @@ static int amd_ir_set_vcpu_affinity(struct irq_data *data, void *vcpu_info)
+ * we should not modify the IRTE
+ */
+ if (!dev_data || !dev_data->use_vapic)
+- return 0;
++ return -EINVAL;
+
+ ir_data->cfg = irqd_cfg(data);
+ pi_data->ir_data = ir_data;
+--
+2.39.5
+
--- /dev/null
+From 76061f8b0ed8a1fe09f31ad5fe5be0e10245cd5c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 22 Apr 2025 04:10:20 +0100
+Subject: net: dsa: mt7530: sync driver-specific behavior of MT7531 variants
+
+From: Daniel Golle <daniel@makrotopia.org>
+
+[ Upstream commit 497041d763016c2e8314d2f6a329a9b77c3797ca ]
+
+MT7531 standalone and MMIO variants found in MT7988 and EN7581 share
+most basic properties. Despite that, assisted_learning_on_cpu_port and
+mtu_enforcement_ingress were only applied for MT7531 but not for MT7988
+or EN7581, causing the expected issues on MMIO devices.
+
+Apply both settings equally also for MT7988 and EN7581 by moving both
+assignments form mt7531_setup() to mt7531_setup_common().
+
+This fixes unwanted flooding of packets due to unknown unicast
+during DA lookup, as well as issues with heterogenous MTU settings.
+
+Fixes: 7f54cc9772ce ("net: dsa: mt7530: split-off common parts from mt7531_setup")
+Signed-off-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Chester A. Unal <chester.a.unal@arinc9.com>
+Link: https://patch.msgid.link/89ed7ec6d4fa0395ac53ad2809742bb1ce61ed12.1745290867.git.daniel@makrotopia.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/mt7530.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
+index 86db6a18c8377..abd61514d3361 100644
+--- a/drivers/net/dsa/mt7530.c
++++ b/drivers/net/dsa/mt7530.c
+@@ -2534,6 +2534,9 @@ mt7531_setup_common(struct dsa_switch *ds)
+ struct mt7530_priv *priv = ds->priv;
+ int ret, i;
+
++ ds->assisted_learning_on_cpu_port = true;
++ ds->mtu_enforcement_ingress = true;
++
+ mt753x_trap_frames(priv);
+
+ /* Enable and reset MIB counters */
+@@ -2673,9 +2676,6 @@ mt7531_setup(struct dsa_switch *ds)
+ if (ret)
+ return ret;
+
+- ds->assisted_learning_on_cpu_port = true;
+- ds->mtu_enforcement_ingress = true;
+-
+ return 0;
+ }
+
+--
+2.39.5
+
--- /dev/null
+From c9e95ef5483a907ff92fd0b0f69b854ebd68fef3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Apr 2025 11:25:56 +0800
+Subject: net: phy: leds: fix memory leak
+
+From: Qingfang Deng <qingfang.deng@siflower.com.cn>
+
+[ Upstream commit b7f0ee992adf601aa00c252418266177eb7ac2bc ]
+
+A network restart test on a router led to an out-of-memory condition,
+which was traced to a memory leak in the PHY LED trigger code.
+
+The root cause is misuse of the devm API. The registration function
+(phy_led_triggers_register) is called from phy_attach_direct, not
+phy_probe, and the unregister function (phy_led_triggers_unregister)
+is called from phy_detach, not phy_remove. This means the register and
+unregister functions can be called multiple times for the same PHY
+device, but devm-allocated memory is not freed until the driver is
+unbound.
+
+This also prevents kmemleak from detecting the leak, as the devm API
+internally stores the allocated pointer.
+
+Fix this by replacing devm_kzalloc/devm_kcalloc with standard
+kzalloc/kcalloc, and add the corresponding kfree calls in the unregister
+path.
+
+Fixes: 3928ee6485a3 ("net: phy: leds: Add support for "link" trigger")
+Fixes: 2e0bc452f472 ("net: phy: leds: add support for led triggers on phy link state change")
+Signed-off-by: Hao Guan <hao.guan@siflower.com.cn>
+Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://patch.msgid.link/20250417032557.2929427-1-dqfext@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/phy/phy_led_triggers.c | 23 +++++++++++++----------
+ 1 file changed, 13 insertions(+), 10 deletions(-)
+
+diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
+index f550576eb9dae..6f9d8da76c4df 100644
+--- a/drivers/net/phy/phy_led_triggers.c
++++ b/drivers/net/phy/phy_led_triggers.c
+@@ -91,9 +91,8 @@ int phy_led_triggers_register(struct phy_device *phy)
+ if (!phy->phy_num_led_triggers)
+ return 0;
+
+- phy->led_link_trigger = devm_kzalloc(&phy->mdio.dev,
+- sizeof(*phy->led_link_trigger),
+- GFP_KERNEL);
++ phy->led_link_trigger = kzalloc(sizeof(*phy->led_link_trigger),
++ GFP_KERNEL);
+ if (!phy->led_link_trigger) {
+ err = -ENOMEM;
+ goto out_clear;
+@@ -103,10 +102,9 @@ int phy_led_triggers_register(struct phy_device *phy)
+ if (err)
+ goto out_free_link;
+
+- phy->phy_led_triggers = devm_kcalloc(&phy->mdio.dev,
+- phy->phy_num_led_triggers,
+- sizeof(struct phy_led_trigger),
+- GFP_KERNEL);
++ phy->phy_led_triggers = kcalloc(phy->phy_num_led_triggers,
++ sizeof(struct phy_led_trigger),
++ GFP_KERNEL);
+ if (!phy->phy_led_triggers) {
+ err = -ENOMEM;
+ goto out_unreg_link;
+@@ -127,11 +125,11 @@ int phy_led_triggers_register(struct phy_device *phy)
+ out_unreg:
+ while (i--)
+ phy_led_trigger_unregister(&phy->phy_led_triggers[i]);
+- devm_kfree(&phy->mdio.dev, phy->phy_led_triggers);
++ kfree(phy->phy_led_triggers);
+ out_unreg_link:
+ phy_led_trigger_unregister(phy->led_link_trigger);
+ out_free_link:
+- devm_kfree(&phy->mdio.dev, phy->led_link_trigger);
++ kfree(phy->led_link_trigger);
+ phy->led_link_trigger = NULL;
+ out_clear:
+ phy->phy_num_led_triggers = 0;
+@@ -145,8 +143,13 @@ void phy_led_triggers_unregister(struct phy_device *phy)
+
+ for (i = 0; i < phy->phy_num_led_triggers; i++)
+ phy_led_trigger_unregister(&phy->phy_led_triggers[i]);
++ kfree(phy->phy_led_triggers);
++ phy->phy_led_triggers = NULL;
+
+- if (phy->led_link_trigger)
++ if (phy->led_link_trigger) {
+ phy_led_trigger_unregister(phy->led_link_trigger);
++ kfree(phy->led_link_trigger);
++ phy->led_link_trigger = NULL;
++ }
+ }
+ EXPORT_SYMBOL_GPL(phy_led_triggers_unregister);
+--
+2.39.5
+
--- /dev/null
+From 4216bb56d96980d62b36a8111a09ef696503f7f7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Apr 2025 11:47:31 -0700
+Subject: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
+
+From: Cong Wang <xiyou.wangcong@gmail.com>
+
+[ Upstream commit 6ccbda44e2cc3d26fd22af54c650d6d5d801addf ]
+
+Similarly to the previous patch, we need to safe guard hfsc_dequeue()
+too. But for this one, we don't have a reliable reproducer.
+
+Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
+Reported-by: Gerrard Tai <gerrard.tai@starlabs.sg>
+Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
+Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
+Link: https://patch.msgid.link/20250417184732.943057-3-xiyou.wangcong@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/sch_hfsc.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
+index ea42708aac7e2..85c296664c9ab 100644
+--- a/net/sched/sch_hfsc.c
++++ b/net/sched/sch_hfsc.c
+@@ -1644,10 +1644,16 @@ hfsc_dequeue(struct Qdisc *sch)
+ if (cl->qdisc->q.qlen != 0) {
+ /* update ed */
+ next_len = qdisc_peek_len(cl->qdisc);
+- if (realtime)
+- update_ed(cl, next_len);
+- else
+- update_d(cl, next_len);
++ /* Check queue length again since some qdisc implementations
++ * (e.g., netem/codel) might empty the queue during the peek
++ * operation.
++ */
++ if (cl->qdisc->q.qlen != 0) {
++ if (realtime)
++ update_ed(cl, next_len);
++ else
++ update_d(cl, next_len);
++ }
+ } else {
+ /* the class becomes passive */
+ eltree_remove(cl);
+--
+2.39.5
+
--- /dev/null
+From f9eab4c2571ce7ac19555b8bad733d02f91cb979 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Apr 2025 11:47:30 -0700
+Subject: net_sched: hfsc: Fix a UAF vulnerability in class handling
+
+From: Cong Wang <xiyou.wangcong@gmail.com>
+
+[ Upstream commit 3df275ef0a6ae181e8428a6589ef5d5231e58b5c ]
+
+This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class
+handling. The issue occurs due to a time-of-check/time-of-use condition
+in hfsc_change_class() when working with certain child qdiscs like netem
+or codel.
+
+The vulnerability works as follows:
+1. hfsc_change_class() checks if a class has packets (q.qlen != 0)
+2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,
+ codel, netem) might drop packets and empty the queue
+3. The code continues assuming the queue is still non-empty, adding
+ the class to vttree
+4. This breaks HFSC scheduler assumptions that only non-empty classes
+ are in vttree
+5. Later, when the class is destroyed, this can lead to a Use-After-Free
+
+The fix adds a second queue length check after qdisc_peek_len() to verify
+the queue wasn't emptied.
+
+Fixes: 21f4d5cc25ec ("net_sched/hfsc: fix curve activation in hfsc_change_class()")
+Reported-by: Gerrard Tai <gerrard.tai@starlabs.sg>
+Reviewed-by: Konstantin Khlebnikov <koct9i@gmail.com>
+Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
+Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
+Link: https://patch.msgid.link/20250417184732.943057-2-xiyou.wangcong@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/sch_hfsc.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
+index 1f0db6c85b09c..ea42708aac7e2 100644
+--- a/net/sched/sch_hfsc.c
++++ b/net/sched/sch_hfsc.c
+@@ -959,6 +959,7 @@ hfsc_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
+
+ if (cl != NULL) {
+ int old_flags;
++ int len = 0;
+
+ if (parentid) {
+ if (cl->cl_parent &&
+@@ -989,9 +990,13 @@ hfsc_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
+ if (usc != NULL)
+ hfsc_change_usc(cl, usc, cur_time);
+
++ if (cl->qdisc->q.qlen != 0)
++ len = qdisc_peek_len(cl->qdisc);
++ /* Check queue length again since some qdisc implementations
++ * (e.g., netem/codel) might empty the queue during the peek
++ * operation.
++ */
+ if (cl->qdisc->q.qlen != 0) {
+- int len = qdisc_peek_len(cl->qdisc);
+-
+ if (cl->cl_flags & HFSC_RSC) {
+ if (old_flags & HFSC_RSC)
+ update_ed(cl, len);
+--
+2.39.5
+
--- /dev/null
+From c36385343b412dfb450f879a77ff414da4ebfafc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 19 Apr 2025 13:14:00 +0200
+Subject: riscv: uprobes: Add missing fence.i after building the XOL buffer
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Björn Töpel <bjorn@rivosinc.com>
+
+[ Upstream commit 7d1d19a11cfbfd8bae1d89cc010b2cc397cd0c48 ]
+
+The XOL (execute out-of-line) buffer is used to single-step the
+replaced instruction(s) for uprobes. The RISC-V port was missing a
+proper fence.i (i$ flushing) after constructing the XOL buffer, which
+can result in incorrect execution of stale/broken instructions.
+
+This was found running the BPF selftests "test_progs:
+uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the
+uprobes tests randomly blew up.
+
+Reviewed-by: Guo Ren <guoren@kernel.org>
+Fixes: 74784081aac8 ("riscv: Add uprobes supported")
+Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
+Link: https://lore.kernel.org/r/20250419111402.1660267-2-bjorn@kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/kernel/probes/uprobes.c | 10 ++--------
+ 1 file changed, 2 insertions(+), 8 deletions(-)
+
+diff --git a/arch/riscv/kernel/probes/uprobes.c b/arch/riscv/kernel/probes/uprobes.c
+index 194f166b2cc40..0d18ee53fd649 100644
+--- a/arch/riscv/kernel/probes/uprobes.c
++++ b/arch/riscv/kernel/probes/uprobes.c
+@@ -161,6 +161,7 @@ void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
+ /* Initialize the slot */
+ void *kaddr = kmap_atomic(page);
+ void *dst = kaddr + (vaddr & ~PAGE_MASK);
++ unsigned long start = (unsigned long)dst;
+
+ memcpy(dst, src, len);
+
+@@ -170,13 +171,6 @@ void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
+ *(uprobe_opcode_t *)dst = __BUG_INSN_32;
+ }
+
++ flush_icache_range(start, start + len);
+ kunmap_atomic(kaddr);
+-
+- /*
+- * We probably need flush_icache_user_page() but it needs vma.
+- * This should work on most of architectures by default. If
+- * architecture needs to do something different it can define
+- * its own version of the function.
+- */
+- flush_dcache_page(page);
+ }
+--
+2.39.5
+
drm-msm-a6xx-handle-gmu-prepare-slumber-hfi-failure.patch
drm-msm-a6xx-avoid-gx-gbit-halt-during-rpm-suspend.patch
drm-msm-a6xx-fix-stale-rpmh-votes-from-gpu.patch
+dma-contiguous-avoid-warning-about-unused-size_bytes.patch
+cpufreq-scmi-fix-null-ptr-deref-in-scmi_cpufreq_get_.patch
+cpufreq-scpi-fix-null-ptr-deref-in-scpi_cpufreq_get_.patch
+cpufreq-cppc-fix-invalid-return-value-in-.get-callba.patch
+net-phy-leds-fix-memory-leak.patch
+tipc-fix-null-pointer-dereference-in-tipc_mon_reinit.patch
+net_sched-hfsc-fix-a-uaf-vulnerability-in-class-hand.patch
+net_sched-hfsc-fix-a-potential-uaf-in-hfsc_dequeue-t.patch
+net-dsa-mt7530-sync-driver-specific-behavior-of-mt75.patch
+iommu-amd-return-an-error-if-vcpu-affinity-is-set-fo.patch
+riscv-uprobes-add-missing-fence.i-after-building-the.patch
--- /dev/null
+From 83fc94f6120ef455e8546affaedffe341ccfb7cf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Apr 2025 14:47:15 +0700
+Subject: tipc: fix NULL pointer dereference in tipc_mon_reinit_self()
+
+From: Tung Nguyen <tung.quang.nguyen@est.tech>
+
+[ Upstream commit d63527e109e811ef11abb1c2985048fdb528b4cb ]
+
+syzbot reported:
+
+tipc: Node number set to 1055423674
+Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
+KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
+CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)
+Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
+Workqueue: events tipc_net_finalize_work
+RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719
+...
+RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246
+RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba
+RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010
+RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000
+R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007
+R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010
+FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140
+ process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238
+ process_scheduled_works kernel/workqueue.c:3319 [inline]
+ worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400
+ kthread+0x3c2/0x780 kernel/kthread.c:464
+ ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
+ ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
+ </TASK>
+...
+RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719
+...
+RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246
+RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba
+RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010
+RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000
+R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007
+R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010
+FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+
+There is a racing condition between workqueue created when enabling
+bearer and another thread created when disabling bearer right after
+that as follow:
+
+enabling_bearer | disabling_bearer
+--------------- | ----------------
+tipc_disc_timeout() |
+{ | bearer_disable()
+ ... | {
+ schedule_work(&tn->work); | tipc_mon_delete()
+ ... | {
+} | ...
+ | write_lock_bh(&mon->lock);
+ | mon->self = NULL;
+ | write_unlock_bh(&mon->lock);
+ | ...
+ | }
+tipc_net_finalize_work() | }
+{ |
+ ... |
+ tipc_net_finalize() |
+ { |
+ ... |
+ tipc_mon_reinit_self() |
+ { |
+ ... |
+ write_lock_bh(&mon->lock); |
+ mon->self->addr = tipc_own_addr(net); |
+ write_unlock_bh(&mon->lock); |
+ ... |
+ } |
+ ... |
+ } |
+ ... |
+} |
+
+'mon->self' is set to NULL in disabling_bearer thread and dereferenced
+later in enabling_bearer thread.
+
+This commit fixes this issue by validating 'mon->self' before assigning
+node address to it.
+
+Reported-by: syzbot+ed60da8d686dc709164c@syzkaller.appspotmail.com
+Fixes: 46cb01eeeb86 ("tipc: update mon's self addr when node addr generated")
+Signed-off-by: Tung Nguyen <tung.quang.nguyen@est.tech>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20250417074826.578115-1-tung.quang.nguyen@est.tech
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/tipc/monitor.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/net/tipc/monitor.c b/net/tipc/monitor.c
+index 9618e4429f0fe..23efd35adaa35 100644
+--- a/net/tipc/monitor.c
++++ b/net/tipc/monitor.c
+@@ -716,7 +716,8 @@ void tipc_mon_reinit_self(struct net *net)
+ if (!mon)
+ continue;
+ write_lock_bh(&mon->lock);
+- mon->self->addr = tipc_own_addr(net);
++ if (mon->self)
++ mon->self->addr = tipc_own_addr(net);
+ write_unlock_bh(&mon->lock);
+ }
+ }
+--
+2.39.5
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
