From: Greg Kroah-Hartman Date: Mon, 23 Mar 2026 09:10:01 +0000 (+0100) Subject: 6.18-stable patches X-Git-Tag: v6.1.167~25 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4ec3c970eaaf54b9c63ff6a4faf99421e7a11d24;p=thirdparty%2Fkernel%2Fstable-queue.git 6.18-stable patches added patches: 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 x86-platform-uv-handle-deconfigured-sockets.patch --- diff --git a/queue-6.18/i2c-cp2615-fix-serial-string-null-deref-at-probe.patch b/queue-6.18/i2c-cp2615-fix-serial-string-null-deref-at-probe.patch new file mode 100644 index 0000000000..4aab603a4b --- /dev/null +++ b/queue-6.18/i2c-cp2615-fix-serial-string-null-deref-at-probe.patch @@ -0,0 +1,42 @@ +From aa79f996eb41e95aed85a1bd7f56bcd6a3842008 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +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 + +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 +Signed-off-by: Johan Hovold +Reviewed-by: Bence Csókás +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/20260309075016.25612-1-johan@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.18/i2c-fsi-fix-a-potential-leak-in-fsi_i2c_probe.patch b/queue-6.18/i2c-fsi-fix-a-potential-leak-in-fsi_i2c_probe.patch new file mode 100644 index 0000000000..b0aa685a73 --- /dev/null +++ b/queue-6.18/i2c-fsi-fix-a-potential-leak-in-fsi_i2c_probe.patch @@ -0,0 +1,36 @@ +From be627abcc0d5dbd5882873bd85fbc18aa3d189ed Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Sun, 1 Mar 2026 17:21:01 +0100 +Subject: i2c: fsi: Fix a potential leak in fsi_i2c_probe() + +From: Christophe JAILLET + +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 +Cc: # v5.3+ +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/fd805c39f8de51edf303856103d782138a1633c8.1772382022.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.18/i2c-pxa-defer-reset-on-armada-3700-when-recovery-is-used.patch b/queue-6.18/i2c-pxa-defer-reset-on-armada-3700-when-recovery-is-used.patch new file mode 100644 index 0000000000..371958f4f7 --- /dev/null +++ b/queue-6.18/i2c-pxa-defer-reset-on-armada-3700-when-recovery-is-used.patch @@ -0,0 +1,130 @@ +From 78a6ee14f8b9e1c8f7c77612122444f3be8dc8cc Mon Sep 17 00:00:00 2001 +From: Gabor Juhos +Date: Thu, 26 Feb 2026 14:11:27 +0100 +Subject: i2c: pxa: defer reset on Armada 3700 when recovery is used + +From: Gabor Juhos + +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 +Tested-by: Robert Marko +Reviewed-by: Linus Walleij +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/20260226-i2c-pxa-fix-i2c-communication-v4-1-797a091dae87@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.18/irqchip-riscv-rpmi-sysmsi-fix-mailbox-channel-leak-in-rpmi_sysmsi_probe.patch b/queue-6.18/irqchip-riscv-rpmi-sysmsi-fix-mailbox-channel-leak-in-rpmi_sysmsi_probe.patch new file mode 100644 index 0000000000..64f77b876a --- /dev/null +++ b/queue-6.18/irqchip-riscv-rpmi-sysmsi-fix-mailbox-channel-leak-in-rpmi_sysmsi_probe.patch @@ -0,0 +1,39 @@ +From 76f0930d6e809234904cf9f0f5f42ee6c1dc694e Mon Sep 17 00:00:00 2001 +From: Felix Gu +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 + +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 +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Reviewed-by: Rahul Pathak +Link: https://patch.msgid.link/20260315-sysmsi-v1-1-5f090c86c2ca@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-riscv-rpmi-sysmsi.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/irqchip/irq-riscv-rpmi-sysmsi.c b/drivers/irqchip/irq-riscv-rpmi-sysmsi.c +index 5c74c561ce31..612f3972f7af 100644 +--- 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 platform_device *pdev) + 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; + } +-- +2.53.0 + diff --git a/queue-6.18/perf-x86-intel-add-missing-branch-counters-constraint-apply.patch b/queue-6.18/perf-x86-intel-add-missing-branch-counters-constraint-apply.patch new file mode 100644 index 0000000000..a2b35622b7 --- /dev/null +++ b/queue-6.18/perf-x86-intel-add-missing-branch-counters-constraint-apply.patch @@ -0,0 +1,105 @@ +From 1d07bbd7ea36ea0b8dfa8068dbe67eb3a32d9590 Mon Sep 17 00:00:00 2001 +From: Dapeng Mi +Date: Sat, 28 Feb 2026 13:33:20 +0800 +Subject: perf/x86/intel: Add missing branch counters constraint apply + +From: Dapeng Mi + +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 +Signed-off-by: Dapeng Mi +Signed-off-by: Peter Zijlstra (Intel) +Link: https://patch.msgid.link/20260228053320.140406-2-dapeng1.mi@linux.intel.com +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -4224,6 +4224,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); +@@ -4283,21 +4296,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)) diff --git a/queue-6.18/perf-x86-move-event-pointer-setup-earlier-in-x86_pmu_enable.patch b/queue-6.18/perf-x86-move-event-pointer-setup-earlier-in-x86_pmu_enable.patch new file mode 100644 index 0000000000..8bf670f13d --- /dev/null +++ b/queue-6.18/perf-x86-move-event-pointer-setup-earlier-in-x86_pmu_enable.patch @@ -0,0 +1,110 @@ +From 8d5fae6011260de209aaf231120e8146b14bc8e0 Mon Sep 17 00:00:00 2001 +From: Breno Leitao +Date: Tue, 10 Mar 2026 03:13:16 -0700 +Subject: perf/x86: Move event pointer setup earlier in x86_pmu_enable() + +From: Breno Leitao + +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: + + 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 +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20260310-perf-v2-1-4a3156fce43c@debian.org +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1359,6 +1359,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; + +@@ -1366,7 +1368,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; diff --git a/queue-6.18/ring-buffer-fix-to-update-per-subbuf-entries-of-persistent-ring-buffer.patch b/queue-6.18/ring-buffer-fix-to-update-per-subbuf-entries-of-persistent-ring-buffer.patch new file mode 100644 index 0000000000..85f216575f --- /dev/null +++ b/queue-6.18/ring-buffer-fix-to-update-per-subbuf-entries-of-persistent-ring-buffer.patch @@ -0,0 +1,37 @@ +From f35dbac6942171dc4ce9398d1d216a59224590a9 Mon Sep 17 00:00:00 2001 +From: "Masami Hiramatsu (Google)" +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) + +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 +Cc: Ian Rogers +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) +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -2017,7 +2017,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; diff --git a/queue-6.18/series b/queue-6.18/series index 4fd5fe1d57..20493634eb 100644 --- a/queue-6.18/series +++ b/queue-6.18/series @@ -182,3 +182,12 @@ 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 usb-serial-f81232-fix-incomplete-serial-port-generation.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 +x86-platform-uv-handle-deconfigured-sockets.patch diff --git a/queue-6.18/tracing-fix-failure-to-read-user-space-from-system-call-trace-events.patch b/queue-6.18/tracing-fix-failure-to-read-user-space-from-system-call-trace-events.patch new file mode 100644 index 0000000000..9ff92d656e --- /dev/null +++ b/queue-6.18/tracing-fix-failure-to-read-user-space-from-system-call-trace-events.patch @@ -0,0 +1,100 @@ +From edca33a56297d5741ccf867669debec116681987 Mon Sep 17 00:00:00 2001 +From: Steven Rostedt +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 + +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 +Cc: Mathieu Desnoyers +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) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 17 +++++++++++++++++ + 1 file changed, 17 insertions(+) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -7346,6 +7346,23 @@ static char *trace_user_fault_read(struc + + 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 diff --git a/queue-6.18/x86-platform-uv-handle-deconfigured-sockets.patch b/queue-6.18/x86-platform-uv-handle-deconfigured-sockets.patch new file mode 100644 index 0000000000..42ff53f02d --- /dev/null +++ b/queue-6.18/x86-platform-uv-handle-deconfigured-sockets.patch @@ -0,0 +1,53 @@ +From 1f6aa5bbf1d0f81a8a2aafc16136e7dd9a609ff3 Mon Sep 17 00:00:00 2001 +From: Kyle Meyer +Date: Fri, 20 Mar 2026 12:19:20 -0500 +Subject: x86/platform/uv: Handle deconfigured sockets + +From: Kyle Meyer + +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 +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Steve Wahl +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/ab2BmGL0ehVkkjKk@hpe.com +Signed-off-by: Greg Kroah-Hartman +--- + 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)