--- /dev/null
+From aa79f996eb41e95aed85a1bd7f56bcd6a3842008 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 9 Mar 2026 08:50:16 +0100
+Subject: i2c: cp2615: fix serial string NULL-deref at probe
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Johan Hovold <johan@kernel.org>
+
+commit aa79f996eb41e95aed85a1bd7f56bcd6a3842008 upstream.
+
+The cp2615 driver uses the USB device serial string as the i2c adapter
+name but does not make sure that the string exists.
+
+Verify that the device has a serial number before accessing it to avoid
+triggering a NULL-pointer dereference (e.g. with malicious devices).
+
+Fixes: 4a7695429ead ("i2c: cp2615: add i2c driver for Silicon Labs' CP2615 Digital Audio Bridge")
+Cc: stable@vger.kernel.org # 5.13
+Cc: Bence Csókás <bence98@sch.bme.hu>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Reviewed-by: Bence Csókás <bence98@sch.bme.hu>
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/20260309075016.25612-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-cp2615.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/i2c/busses/i2c-cp2615.c
++++ b/drivers/i2c/busses/i2c-cp2615.c
+@@ -298,6 +298,9 @@ cp2615_i2c_probe(struct usb_interface *u
+ if (!adap)
+ return -ENOMEM;
+
++ if (!usbdev->serial)
++ return -EINVAL;
++
+ strscpy(adap->name, usbdev->serial, sizeof(adap->name));
+ adap->owner = THIS_MODULE;
+ adap->dev.parent = &usbif->dev;
--- /dev/null
+From be627abcc0d5dbd5882873bd85fbc18aa3d189ed Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sun, 1 Mar 2026 17:21:01 +0100
+Subject: i2c: fsi: Fix a potential leak in fsi_i2c_probe()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit be627abcc0d5dbd5882873bd85fbc18aa3d189ed upstream.
+
+In the commit in Fixes:, when the code has been updated to use an explicit
+for loop, instead of for_each_available_child_of_node(), the assumption
+that a reference to a device_node structure would be released at each
+iteration has been broken.
+
+Now, an explicit of_node_put() is needed to release the reference.
+
+Fixes: 095561f476ab ("i2c: fsi: Create busses for all ports")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Cc: <stable@vger.kernel.org> # v5.3+
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/fd805c39f8de51edf303856103d782138a1633c8.1772382022.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-fsi.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/i2c/busses/i2c-fsi.c
++++ b/drivers/i2c/busses/i2c-fsi.c
+@@ -728,6 +728,7 @@ static int fsi_i2c_probe(struct device *
+ rc = i2c_add_adapter(&port->adapter);
+ if (rc < 0) {
+ dev_err(dev, "Failed to register adapter: %d\n", rc);
++ of_node_put(np);
+ kfree(port);
+ continue;
+ }
--- /dev/null
+From 78a6ee14f8b9e1c8f7c77612122444f3be8dc8cc Mon Sep 17 00:00:00 2001
+From: Gabor Juhos <j4g8y7@gmail.com>
+Date: Thu, 26 Feb 2026 14:11:27 +0100
+Subject: i2c: pxa: defer reset on Armada 3700 when recovery is used
+
+From: Gabor Juhos <j4g8y7@gmail.com>
+
+commit 78a6ee14f8b9e1c8f7c77612122444f3be8dc8cc upstream.
+
+The I2C communication is completely broken on the Armada 3700 platform
+since commit 0b01392c18b9 ("i2c: pxa: move to generic GPIO recovery").
+
+For example, on the Methode uDPU board, probing of the two onboard
+temperature sensors fails ...
+
+ [ 7.271713] i2c i2c-0: using pinctrl states for GPIO recovery
+ [ 7.277503] i2c i2c-0: PXA I2C adapter
+ [ 7.282199] i2c i2c-1: using pinctrl states for GPIO recovery
+ [ 7.288241] i2c i2c-1: PXA I2C adapter
+ [ 7.292947] sfp sfp-eth1: Host maximum power 3.0W
+ [ 7.299614] sfp sfp-eth0: Host maximum power 3.0W
+ [ 7.308178] lm75 1-0048: supply vs not found, using dummy regulator
+ [ 32.489631] lm75 1-0048: probe with driver lm75 failed with error -121
+ [ 32.496833] lm75 1-0049: supply vs not found, using dummy regulator
+ [ 82.890614] lm75 1-0049: probe with driver lm75 failed with error -121
+
+... and accessing the plugged-in SFP modules also does not work:
+
+ [ 511.298537] sfp sfp-eth1: please wait, module slow to respond
+ [ 536.488530] sfp sfp-eth0: please wait, module slow to respond
+ ...
+ [ 1065.688536] sfp sfp-eth1: failed to read EEPROM: -EREMOTEIO
+ [ 1090.888532] sfp sfp-eth0: failed to read EEPROM: -EREMOTEIO
+
+After a discussion [1], there was an attempt to fix the problem by
+reverting the offending change by commit 7b211c767121 ("Revert "i2c:
+pxa: move to generic GPIO recovery""), but that only helped to fix
+the issue in the 6.1.y stable tree. The reason behind the partial succes
+is that there was another change in commit 20cb3fce4d60 ("i2c: Set i2c
+pinctrl recovery info from it's device pinctrl") in the 6.3-rc1 cycle
+which broke things further.
+
+The cause of the problem is the same in case of both offending commits
+mentioned above. Namely, the I2C core code changes the pinctrl state to
+GPIO while running the recovery initialization code. Although the PXA
+specific initialization also does this, but the key difference is that
+it happens before the controller is getting enabled in i2c_pxa_reset(),
+whereas in the case of the generic initialization it happens after that.
+
+Change the code to reset the controller only before the first transfer
+instead of before registering the controller. This ensures that the
+controller is not enabled at the time when the generic recovery code
+performs the pinctrl state changes, thus avoids the problem described
+above.
+
+As the result this change restores the original behaviour, which in
+turn makes the I2C communication to work again as it can be seen from
+the following log:
+
+ [ 7.363250] i2c i2c-0: using pinctrl states for GPIO recovery
+ [ 7.369041] i2c i2c-0: PXA I2C adapter
+ [ 7.373673] i2c i2c-1: using pinctrl states for GPIO recovery
+ [ 7.379742] i2c i2c-1: PXA I2C adapter
+ [ 7.384506] sfp sfp-eth1: Host maximum power 3.0W
+ [ 7.393013] sfp sfp-eth0: Host maximum power 3.0W
+ [ 7.399266] lm75 1-0048: supply vs not found, using dummy regulator
+ [ 7.407257] hwmon hwmon0: temp1_input not attached to any thermal zone
+ [ 7.413863] lm75 1-0048: hwmon0: sensor 'tmp75c'
+ [ 7.418746] lm75 1-0049: supply vs not found, using dummy regulator
+ [ 7.426371] hwmon hwmon1: temp1_input not attached to any thermal zone
+ [ 7.432972] lm75 1-0049: hwmon1: sensor 'tmp75c'
+ [ 7.755092] sfp sfp-eth1: module MENTECHOPTO POS22-LDCC-KR rev 1.0 sn MNC208U90009 dc 200828
+ [ 7.764997] mvneta d0040000.ethernet eth1: unsupported SFP module: no common interface modes
+ [ 7.785362] sfp sfp-eth0: module Mikrotik S-RJ01 rev 1.0 sn 61B103C55C58 dc 201022
+ [ 7.803426] hwmon hwmon2: temp1_input not attached to any thermal zone
+
+Link: https://lore.kernel.org/r/20230926160255.330417-1-robert.marko@sartura.hr #1
+
+Cc: stable@vger.kernel.org # 6.3+
+Fixes: 20cb3fce4d60 ("i2c: Set i2c pinctrl recovery info from it's device pinctrl")
+Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
+Tested-by: Robert Marko <robert.marko@sartura.hr>
+Reviewed-by: Linus Walleij <linusw@kernel.org>
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/20260226-i2c-pxa-fix-i2c-communication-v4-1-797a091dae87@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-pxa.c | 17 ++++++++++++++++-
+ 1 file changed, 16 insertions(+), 1 deletion(-)
+
+--- a/drivers/i2c/busses/i2c-pxa.c
++++ b/drivers/i2c/busses/i2c-pxa.c
+@@ -268,6 +268,7 @@ struct pxa_i2c {
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pinctrl_default;
+ struct pinctrl_state *pinctrl_recovery;
++ bool reset_before_xfer;
+ };
+
+ #define _IBMR(i2c) ((i2c)->reg_ibmr)
+@@ -1144,6 +1145,11 @@ static int i2c_pxa_xfer(struct i2c_adapt
+ {
+ struct pxa_i2c *i2c = adap->algo_data;
+
++ if (i2c->reset_before_xfer) {
++ i2c_pxa_reset(i2c);
++ i2c->reset_before_xfer = false;
++ }
++
+ return i2c_pxa_internal_xfer(i2c, msgs, num, i2c_pxa_do_xfer);
+ }
+
+@@ -1521,7 +1527,16 @@ static int i2c_pxa_probe(struct platform
+ }
+ }
+
+- i2c_pxa_reset(i2c);
++ /*
++ * Skip reset on Armada 3700 when recovery is used to avoid
++ * controller hang due to the pinctrl state changes done by
++ * the generic recovery initialization code. The reset will
++ * be performed later, prior to the first transfer.
++ */
++ if (i2c_type == REGS_A3700 && i2c->adap.bus_recovery_info)
++ i2c->reset_before_xfer = true;
++ else
++ i2c_pxa_reset(i2c);
+
+ ret = i2c_add_numbered_adapter(&i2c->adap);
+ if (ret < 0)
--- /dev/null
+From 76f0930d6e809234904cf9f0f5f42ee6c1dc694e Mon Sep 17 00:00:00 2001
+From: Felix Gu <ustc.gu@gmail.com>
+Date: Sun, 15 Mar 2026 15:17:54 +0800
+Subject: irqchip/riscv-rpmi-sysmsi: Fix mailbox channel leak in rpmi_sysmsi_probe()
+
+From: Felix Gu <ustc.gu@gmail.com>
+
+commit 76f0930d6e809234904cf9f0f5f42ee6c1dc694e upstream.
+
+When riscv_acpi_get_gsi_info() fails, the mailbox channel previously
+requested via mbox_request_channel() is not freed. Add the missing
+mbox_free_channel() call to prevent the resource leak.
+
+Fixes: 4752b0cfbc37 ("irqchip/riscv-rpmi-sysmsi: Add ACPI support")
+Signed-off-by: Felix Gu <ustc.gu@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Cc: stable@vger.kernel.org
+Reviewed-by: Rahul Pathak <rahul@summations.net>
+Link: https://patch.msgid.link/20260315-sysmsi-v1-1-5f090c86c2ca@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-riscv-rpmi-sysmsi.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/irqchip/irq-riscv-rpmi-sysmsi.c
++++ b/drivers/irqchip/irq-riscv-rpmi-sysmsi.c
+@@ -250,6 +250,7 @@ static int rpmi_sysmsi_probe(struct plat
+ rc = riscv_acpi_get_gsi_info(fwnode, &priv->gsi_base, &id,
+ &nr_irqs, NULL);
+ if (rc) {
++ mbox_free_channel(priv->chan);
+ dev_err(dev, "failed to find GSI mapping\n");
+ return rc;
+ }
--- /dev/null
+From 1d07bbd7ea36ea0b8dfa8068dbe67eb3a32d9590 Mon Sep 17 00:00:00 2001
+From: Dapeng Mi <dapeng1.mi@linux.intel.com>
+Date: Sat, 28 Feb 2026 13:33:20 +0800
+Subject: perf/x86/intel: Add missing branch counters constraint apply
+
+From: Dapeng Mi <dapeng1.mi@linux.intel.com>
+
+commit 1d07bbd7ea36ea0b8dfa8068dbe67eb3a32d9590 upstream.
+
+When running the command:
+'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1',
+a "shift-out-of-bounds" warning is reported on CWF.
+
+ UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
+ shift exponent 64 is too large for 64-bit type 'long long unsigned int'
+ ......
+ intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
+ intel_pmu_lbr_save_brstack+0xc0/0x4c0
+ setup_arch_pebs_sample_data+0x114b/0x2400
+
+The warning occurs because the second "instructions:p" event, which
+involves branch counters sampling, is incorrectly programmed to fixed
+counter 0 instead of the general-purpose (GP) counters 0-3 that support
+branch counters sampling. Currently only GP counters 0-3 support branch
+counters sampling on CWF, any event involving branch counters sampling
+should be programed on GP counters 0-3. Since the counter index of fixed
+counter 0 is 32, it leads to the "src" value in below code is right
+shifted 64 bits and trigger the "shift-out-of-bounds" warning.
+
+cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK;
+
+The root cause is the loss of the branch counters constraint for the
+new event in the branch counters sampling event group. Since it isn't
+yet part of the sibling list. This results in the second
+"instructions:p" event being programmed on fixed counter 0 incorrectly
+instead of the appropriate GP counters 0-3.
+
+To address this, we apply the missing branch counters constraint for
+the last event in the group. Additionally, we introduce a new function,
+`intel_set_branch_counter_constr()`, to apply the branch counters
+constraint and avoid code duplication.
+
+Fixes: 33744916196b ("perf/x86/intel: Support branch counters logging")
+Reported-by: Xudong Hao <xudong.hao@intel.com>
+Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://patch.msgid.link/20260228053320.140406-2-dapeng1.mi@linux.intel.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/events/intel/core.c | 31 +++++++++++++++++++++----------
+ 1 file changed, 21 insertions(+), 10 deletions(-)
+
+--- a/arch/x86/events/intel/core.c
++++ b/arch/x86/events/intel/core.c
+@@ -4367,6 +4367,19 @@ static inline void intel_pmu_set_acr_cau
+ event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64);
+ }
+
++static inline int intel_set_branch_counter_constr(struct perf_event *event,
++ int *num)
++{
++ if (branch_sample_call_stack(event))
++ return -EINVAL;
++ if (branch_sample_counters(event)) {
++ (*num)++;
++ event->hw.dyn_constraint &= x86_pmu.lbr_counters;
++ }
++
++ return 0;
++}
++
+ static int intel_pmu_hw_config(struct perf_event *event)
+ {
+ int ret = x86_pmu_hw_config(event);
+@@ -4437,21 +4450,19 @@ static int intel_pmu_hw_config(struct pe
+ * group, which requires the extra space to store the counters.
+ */
+ leader = event->group_leader;
+- if (branch_sample_call_stack(leader))
++ if (intel_set_branch_counter_constr(leader, &num))
+ return -EINVAL;
+- if (branch_sample_counters(leader)) {
+- num++;
+- leader->hw.dyn_constraint &= x86_pmu.lbr_counters;
+- }
+ leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS;
+
+ for_each_sibling_event(sibling, leader) {
+- if (branch_sample_call_stack(sibling))
++ if (intel_set_branch_counter_constr(sibling, &num))
++ return -EINVAL;
++ }
++
++ /* event isn't installed as a sibling yet. */
++ if (event != leader) {
++ if (intel_set_branch_counter_constr(event, &num))
+ return -EINVAL;
+- if (branch_sample_counters(sibling)) {
+- num++;
+- sibling->hw.dyn_constraint &= x86_pmu.lbr_counters;
+- }
+ }
+
+ if (num > fls(x86_pmu.lbr_counters))
--- /dev/null
+From 8d5fae6011260de209aaf231120e8146b14bc8e0 Mon Sep 17 00:00:00 2001
+From: Breno Leitao <leitao@debian.org>
+Date: Tue, 10 Mar 2026 03:13:16 -0700
+Subject: perf/x86: Move event pointer setup earlier in x86_pmu_enable()
+
+From: Breno Leitao <leitao@debian.org>
+
+commit 8d5fae6011260de209aaf231120e8146b14bc8e0 upstream.
+
+A production AMD EPYC system crashed with a NULL pointer dereference
+in the PMU NMI handler:
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000198
+ RIP: x86_perf_event_update+0xc/0xa0
+ Call Trace:
+ <NMI>
+ amd_pmu_v2_handle_irq+0x1a6/0x390
+ perf_event_nmi_handler+0x24/0x40
+
+The faulting instruction is `cmpq $0x0, 0x198(%rdi)` with RDI=0,
+corresponding to the `if (unlikely(!hwc->event_base))` check in
+x86_perf_event_update() where hwc = &event->hw and event is NULL.
+
+drgn inspection of the vmcore on CPU 106 showed a mismatch between
+cpuc->active_mask and cpuc->events[]:
+
+ active_mask: 0x1e (bits 1, 2, 3, 4)
+ events[1]: 0xff1100136cbd4f38 (valid)
+ events[2]: 0x0 (NULL, but active_mask bit 2 set)
+ events[3]: 0xff1100076fd2cf38 (valid)
+ events[4]: 0xff1100079e990a90 (valid)
+
+The event that should occupy events[2] was found in event_list[2]
+with hw.idx=2 and hw.state=0x0, confirming x86_pmu_start() had run
+(which clears hw.state and sets active_mask) but events[2] was
+never populated.
+
+Another event (event_list[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH),
+showing it was stopped when the PMU rescheduled events, confirming the
+throttle-then-reschedule sequence occurred.
+
+The root cause is commit 7e772a93eb61 ("perf/x86: Fix NULL event access
+and potential PEBS record loss") which moved the cpuc->events[idx]
+assignment out of x86_pmu_start() and into step 2 of x86_pmu_enable(),
+after the PERF_HES_ARCH check. This broke any path that calls
+pmu->start() without going through x86_pmu_enable() -- specifically
+the unthrottle path:
+
+ perf_adjust_freq_unthr_events()
+ -> perf_event_unthrottle_group()
+ -> perf_event_unthrottle()
+ -> event->pmu->start(event, 0)
+ -> x86_pmu_start() // sets active_mask but not events[]
+
+The race sequence is:
+
+ 1. A group of perf events overflows, triggering group throttle via
+ perf_event_throttle_group(). All events are stopped: active_mask
+ bits cleared, events[] preserved (x86_pmu_stop no longer clears
+ events[] after commit 7e772a93eb61).
+
+ 2. While still throttled (PERF_HES_STOPPED), x86_pmu_enable() runs
+ due to other scheduling activity. Stopped events that need to
+ move counters get PERF_HES_ARCH set and events[old_idx] cleared.
+ In step 2 of x86_pmu_enable(), PERF_HES_ARCH causes these events
+ to be skipped -- events[new_idx] is never set.
+
+ 3. The timer tick unthrottles the group via pmu->start(). Since
+ commit 7e772a93eb61 removed the events[] assignment from
+ x86_pmu_start(), active_mask[new_idx] is set but events[new_idx]
+ remains NULL.
+
+ 4. A PMC overflow NMI fires. The handler iterates active counters,
+ finds active_mask[2] set, reads events[2] which is NULL, and
+ crashes dereferencing it.
+
+Move the cpuc->events[hwc->idx] assignment in x86_pmu_enable() to
+before the PERF_HES_ARCH check, so that events[] is populated even
+for events that are not immediately started. This ensures the
+unthrottle path via pmu->start() always finds a valid event pointer.
+
+Fixes: 7e772a93eb61 ("perf/x86: Fix NULL event access and potential PEBS record loss")
+Signed-off-by: Breno Leitao <leitao@debian.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260310-perf-v2-1-4a3156fce43c@debian.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/events/core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/events/core.c
++++ b/arch/x86/events/core.c
+@@ -1369,6 +1369,8 @@ static void x86_pmu_enable(struct pmu *p
+ else if (i < n_running)
+ continue;
+
++ cpuc->events[hwc->idx] = event;
++
+ if (hwc->state & PERF_HES_ARCH)
+ continue;
+
+@@ -1376,7 +1378,6 @@ static void x86_pmu_enable(struct pmu *p
+ * if cpuc->enabled = 0, then no wrmsr as
+ * per x86_pmu_enable_event()
+ */
+- cpuc->events[hwc->idx] = event;
+ x86_pmu_start(event, PERF_EF_RELOAD);
+ }
+ cpuc->n_added = 0;
--- /dev/null
+From f35dbac6942171dc4ce9398d1d216a59224590a9 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Thu, 19 Mar 2026 18:12:19 +0900
+Subject: ring-buffer: Fix to update per-subbuf entries of persistent ring buffer
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit f35dbac6942171dc4ce9398d1d216a59224590a9 upstream.
+
+Since the validation loop in rb_meta_validate_events() updates the same
+cpu_buffer->head_page->entries, the other subbuf entries are not updated.
+Fix to use head_page to update the entries field, since it is the cursor
+in this loop.
+
+Cc: stable@vger.kernel.org
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Ian Rogers <irogers@google.com>
+Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events")
+Link: https://patch.msgid.link/177391153882.193994.17158784065013676533.stgit@mhiramat.tok.corp.google.com
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -2052,7 +2052,7 @@ static void rb_meta_validate_events(stru
+
+ entries += ret;
+ entry_bytes += local_read(&head_page->page->commit);
+- local_set(&cpu_buffer->head_page->entries, ret);
++ local_set(&head_page->entries, ret);
+
+ if (head_page == cpu_buffer->commit_page)
+ break;
hwmon-pmbus-mp2975-add-error-check-for-pmbus_read_word_data-return-value.patch
hwmon-pmbus-mp2869-check-pmbus_read_byte_data-before-using-its-return-value.patch
hwmon-pmbus-isl68137-fix-unchecked-return-value-and-use-sysfs_emit.patch
+i2c-cp2615-fix-serial-string-null-deref-at-probe.patch
+i2c-fsi-fix-a-potential-leak-in-fsi_i2c_probe.patch
+i2c-pxa-defer-reset-on-armada-3700-when-recovery-is-used.patch
+irqchip-riscv-rpmi-sysmsi-fix-mailbox-channel-leak-in-rpmi_sysmsi_probe.patch
+perf-x86-intel-add-missing-branch-counters-constraint-apply.patch
+perf-x86-move-event-pointer-setup-earlier-in-x86_pmu_enable.patch
+ring-buffer-fix-to-update-per-subbuf-entries-of-persistent-ring-buffer.patch
+tracing-fix-failure-to-read-user-space-from-system-call-trace-events.patch
+tracing-fix-trace_marker-copy-link-list-updates.patch
+x86-mce-amd-check-smca-feature-bit-before-accessing-smca-msrs.patch
+x86-platform-uv-handle-deconfigured-sockets.patch
--- /dev/null
+From edca33a56297d5741ccf867669debec116681987 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Mon, 16 Mar 2026 13:07:34 -0400
+Subject: tracing: Fix failure to read user space from system call trace events
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit edca33a56297d5741ccf867669debec116681987 upstream.
+
+The system call trace events call trace_user_fault_read() to read the user
+space part of some system calls. This is done by grabbing a per-cpu
+buffer, disabling migration, enabling preemption, calling
+copy_from_user(), disabling preemption, enabling migration and checking if
+the task was preempted while preemption was enabled. If it was, the buffer
+is considered corrupted and it tries again.
+
+There's a safety mechanism that will fail out of this loop if it fails 100
+times (with a warning). That warning message was triggered in some
+pi_futex stress tests. Enabling the sched_switch trace event and
+traceoff_on_warning, showed the problem:
+
+ pi_mutex_hammer-1375 [006] d..21 138.981648: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981651: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981656: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981659: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981664: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981667: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981671: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981675: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981679: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981682: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981687: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981690: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981695: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981698: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981703: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981706: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981711: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981714: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981719: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981722: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981727: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981730: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+ pi_mutex_hammer-1375 [006] d..21 138.981735: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0
+ migration/6-47 [006] d..2. 138.981738: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95
+
+What happened was the task 1375 was flagged to be migrated. When
+preemption was enabled, the migration thread woke up to migrate that task,
+but failed because migration for that task was disabled. This caused the
+loop to fail to exit because the task scheduled out while trying to read
+user space.
+
+Every time the task enabled preemption the migration thread would schedule
+in, try to migrate the task, fail and let the task continue. But because
+the loop would only enable preemption with migration disabled, it would
+always fail because each time it enabled preemption to read user space,
+the migration thread would try to migrate it.
+
+To solve this, when the loop fails to read user space without being
+scheduled out, enabled and disable preemption with migration enabled. This
+will allow the migration task to successfully migrate the task and the
+next loop should succeed to read user space without being scheduled out.
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Link: https://patch.msgid.link/20260316130734.1858a998@gandalf.local.home
+Fixes: 64cf7d058a005 ("tracing: Have trace_marker use per-cpu data to read user space")
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 17 +++++++++++++++++
+ 1 file changed, 17 insertions(+)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -7546,6 +7546,23 @@ char *trace_user_fault_read(struct trace
+
+ do {
+ /*
++ * It is possible that something is trying to migrate this
++ * task. What happens then, is when preemption is enabled,
++ * the migration thread will preempt this task, try to
++ * migrate it, fail, then let it run again. That will
++ * cause this to loop again and never succeed.
++ * On failures, enabled and disable preemption with
++ * migration enabled, to allow the migration thread to
++ * migrate this task.
++ */
++ if (trys) {
++ preempt_enable_notrace();
++ preempt_disable_notrace();
++ cpu = smp_processor_id();
++ buffer = per_cpu_ptr(tinfo->tbuf, cpu)->buf;
++ }
++
++ /*
+ * If for some reason, copy_from_user() always causes a context
+ * switch, this would then cause an infinite loop.
+ * If this task is preempted by another user space task, it
--- /dev/null
+From 07183aac4a6828e474f00b37c9d795d0d99e18a7 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Wed, 18 Mar 2026 18:55:12 -0400
+Subject: tracing: Fix trace_marker copy link list updates
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit 07183aac4a6828e474f00b37c9d795d0d99e18a7 upstream.
+
+When the "copy_trace_marker" option is enabled for an instance, anything
+written into /sys/kernel/tracing/trace_marker is also copied into that
+instances buffer. When the option is set, that instance's trace_array
+descriptor is added to the marker_copies link list. This list is protected
+by RCU, as all iterations uses an RCU protected list traversal.
+
+When the instance is deleted, all the flags that were enabled are cleared.
+This also clears the copy_trace_marker flag and removes the trace_array
+descriptor from the list.
+
+The issue is after the flags are called, a direct call to
+update_marker_trace() is performed to clear the flag. This function
+returns true if the state of the flag changed and false otherwise. If it
+returns true here, synchronize_rcu() is called to make sure all readers
+see that its removed from the list.
+
+But since the flag was already cleared, the state does not change and the
+synchronization is never called, leaving a possible UAF bug.
+
+Move the clearing of all flags below the updating of the copy_trace_marker
+option which then makes sure the synchronization is performed.
+
+Also use the flag for checking the state in update_marker_trace() instead
+of looking at if the list is empty.
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Link: https://patch.msgid.link/20260318185512.1b6c7db4@gandalf.local.home
+Fixes: 7b382efd5e8a ("tracing: Allow the top level trace_marker to write into another instances")
+Reported-by: Sasha Levin <sashal@kernel.org>
+Closes: https://lore.kernel.org/all/20260225133122.237275-1-sashal@kernel.org/
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 19 ++++++++++---------
+ 1 file changed, 10 insertions(+), 9 deletions(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -567,7 +567,7 @@ static bool update_marker_trace(struct t
+ lockdep_assert_held(&event_mutex);
+
+ if (enabled) {
+- if (!list_empty(&tr->marker_list))
++ if (tr->trace_flags & TRACE_ITER(COPY_MARKER))
+ return false;
+
+ list_add_rcu(&tr->marker_list, &marker_copies);
+@@ -575,10 +575,10 @@ static bool update_marker_trace(struct t
+ return true;
+ }
+
+- if (list_empty(&tr->marker_list))
++ if (!(tr->trace_flags & TRACE_ITER(COPY_MARKER)))
+ return false;
+
+- list_del_init(&tr->marker_list);
++ list_del_rcu(&tr->marker_list);
+ tr->trace_flags &= ~TRACE_ITER(COPY_MARKER);
+ return true;
+ }
+@@ -10547,18 +10547,19 @@ static int __remove_instance(struct trac
+
+ list_del(&tr->list);
+
+- /* Disable all the flags that were enabled coming in */
+- for (i = 0; i < TRACE_FLAGS_MAX_SIZE; i++) {
+- if ((1ULL << i) & ZEROED_TRACE_FLAGS)
+- set_tracer_flag(tr, 1ULL << i, 0);
+- }
+-
+ if (printk_trace == tr)
+ update_printk_trace(&global_trace);
+
++ /* Must be done before disabling all the flags */
+ if (update_marker_trace(tr, 0))
+ synchronize_rcu();
+
++ /* Disable all the flags that were enabled coming in */
++ for (i = 0; i < TRACE_FLAGS_MAX_SIZE; i++) {
++ if ((1ULL << i) & ZEROED_TRACE_FLAGS)
++ set_tracer_flag(tr, 1ULL << i, 0);
++ }
++
+ tracing_set_nop(tr);
+ clear_ftrace_function_probes(tr);
+ event_trace_del_tracer(tr);
--- /dev/null
+From 201bc182ad6333468013f1af0719ffe125826b6a Mon Sep 17 00:00:00 2001
+From: William Roche <william.roche@oracle.com>
+Date: Tue, 17 Mar 2026 10:38:10 +0000
+Subject: x86/mce/amd: Check SMCA feature bit before accessing SMCA MSRs
+
+From: William Roche <william.roche@oracle.com>
+
+commit 201bc182ad6333468013f1af0719ffe125826b6a upstream.
+
+People do effort to inject MCEs into guests in order to simulate/test
+handling of hardware errors. The real use case behind it is testing the
+handling of SIGBUS which the memory failure code sends to the process.
+
+If that process is QEMU, instead of killing the whole guest, the MCE can
+be injected into the guest kernel so that latter can attempt proper
+handling and kill the user *process* in the guest, instead, which
+caused the MCE. The assumption being here that the whole injection flow
+can supply enough information that the guest kernel can pinpoint the
+right process. But that's a different topic...
+
+Regardless of virtualization or not, access to SMCA-specific registers
+like MCA_DESTAT should only be done after having checked the smca
+feature bit. And there are AMD machines like Bulldozer (the one before
+Zen1) which do support deferred errors but are not SMCA machines.
+
+Therefore, properly check the feature bit before accessing related MSRs.
+
+ [ bp: Rewrite commit message. ]
+
+Fixes: 7cb735d7c0cb ("x86/mce: Unify AMD DFR handler with MCA Polling")
+Signed-off-by: William Roche <william.roche@oracle.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20260218163025.1316501-1-william.roche@oracle.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/amd.c | 17 +++++++++++------
+ 1 file changed, 11 insertions(+), 6 deletions(-)
+
+diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
+index da13c1e37f87..a030ee4cecc2 100644
+--- a/arch/x86/kernel/cpu/mce/amd.c
++++ b/arch/x86/kernel/cpu/mce/amd.c
+@@ -875,13 +875,18 @@ void amd_clear_bank(struct mce *m)
+ {
+ amd_reset_thr_limit(m->bank);
+
+- /* Clear MCA_DESTAT for all deferred errors even those logged in MCA_STATUS. */
+- if (m->status & MCI_STATUS_DEFERRED)
+- mce_wrmsrq(MSR_AMD64_SMCA_MCx_DESTAT(m->bank), 0);
++ if (mce_flags.smca) {
++ /*
++ * Clear MCA_DESTAT for all deferred errors even those
++ * logged in MCA_STATUS.
++ */
++ if (m->status & MCI_STATUS_DEFERRED)
++ mce_wrmsrq(MSR_AMD64_SMCA_MCx_DESTAT(m->bank), 0);
+
+- /* Don't clear MCA_STATUS if MCA_DESTAT was used exclusively. */
+- if (m->kflags & MCE_CHECK_DFR_REGS)
+- return;
++ /* Don't clear MCA_STATUS if MCA_DESTAT was used exclusively. */
++ if (m->kflags & MCE_CHECK_DFR_REGS)
++ return;
++ }
+
+ mce_wrmsrq(mca_msr_reg(m->bank, MCA_STATUS), 0);
+ }
+--
+2.53.0
+
--- /dev/null
+From 1f6aa5bbf1d0f81a8a2aafc16136e7dd9a609ff3 Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle.meyer@hpe.com>
+Date: Fri, 20 Mar 2026 12:19:20 -0500
+Subject: x86/platform/uv: Handle deconfigured sockets
+
+From: Kyle Meyer <kyle.meyer@hpe.com>
+
+commit 1f6aa5bbf1d0f81a8a2aafc16136e7dd9a609ff3 upstream.
+
+When a socket is deconfigured, it's mapped to SOCK_EMPTY (0xffff). This causes
+a panic while allocating UV hub info structures.
+
+Fix this by using NUMA_NO_NODE, allowing UV hub info structures to be
+allocated on valid nodes.
+
+Fixes: 8a50c5851927 ("x86/platform/uv: UV support for sub-NUMA clustering")
+Signed-off-by: Kyle Meyer <kyle.meyer@hpe.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Steve Wahl <steve.wahl@hpe.com>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/ab2BmGL0ehVkkjKk@hpe.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/apic/x2apic_uv_x.c | 18 ++++++++++++++++--
+ 1 file changed, 16 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/apic/x2apic_uv_x.c
++++ b/arch/x86/kernel/apic/x2apic_uv_x.c
+@@ -1708,8 +1708,22 @@ static void __init uv_system_init_hub(vo
+ struct uv_hub_info_s *new_hub;
+
+ /* Allocate & fill new per hub info list */
+- new_hub = (bid == 0) ? &uv_hub_info_node0
+- : kzalloc_node(bytes, GFP_KERNEL, uv_blade_to_node(bid));
++ if (bid == 0) {
++ new_hub = &uv_hub_info_node0;
++ } else {
++ int nid;
++
++ /*
++ * Deconfigured sockets are mapped to SOCK_EMPTY. Use
++ * NUMA_NO_NODE to allocate on a valid node.
++ */
++ nid = uv_blade_to_node(bid);
++ if (nid == SOCK_EMPTY)
++ nid = NUMA_NO_NODE;
++
++ new_hub = kzalloc_node(bytes, GFP_KERNEL, nid);
++ }
++
+ if (WARN_ON_ONCE(!new_hub)) {
+ /* do not kfree() bid 0, which is statically allocated */
+ while (--bid > 0)
projects / thirdparty / kernel / stable-queue.git / commitdiff
