- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/6] Updates of HiSilicon Uncore L3C PMU
by Yushan Wang 25 Sep '25

25 Sep '25

From: Qizhi Zhang <zhangqizhi3(a)h-partners.com> Updates of HiSilicon Uncore L3C PMU Support new version of L3C PMU, which supports extended events space which can be controlled in up to 2 extra address spaces with separate overflow interrupts. The layout of the control/event registers are kept the same. The extended events with original ones together cover the monitoring job of all transactions on L3C. That's said, the driver supports finer granual statistics of L3 cache with separated and dedicated PMUs, and a new operand `ext` to give a hint of to which part should perf counting command be delivered. The extended events is specified with `ext=[1|2]` option for the driver to distinguish: perf stat -e hisi_sccl0_l3c0_0/event=<event_id>,ext=<ext>/ Currently only event option using config bit [7, 0]. There's still plenty unused space. Make ext using config [16, 17] and reserve bit [15, 8] for event option for future extension. With the capability of extra counters, number of counters for HiSilicon uncore PMU could reach up to 24, the usedmap is extended accordingly. The hw_perf_event::event_base is initialized to the base MMIO address of the event and will be used for later control, overflow handling and counts readout. We still make use of the Uncore PMU framework for handling the events and interrupt migration on CPU hotplug. The framework's cpuhp callback will handle the event migration and interrupt migration of orginial event, if PMU supports extended events then the interrupt of extended events is migrated to the same CPU choosed by the framework. A new HID of HISI0215 is used for this version of L3C PMU. Some necessary refactor is included, allowing the framework to cope with the new version of driver. --- Qizhi Zhang (3): Revert "Documentation: hisi-pmu: Add introduction to HiSilicon V3 PMU" Revert "Documentation: hisi-pmu: Fix of minor format error" Revert "drivers/perf: hisi: Add support for L3C PMU v3" Yicong Yang (1): drivers/perf: hisi: Add support for L3C PMU v3 Yushan Wang (2): Documentation: hisi-pmu: Fix of minor format error Documentation: hisi-pmu: Add introduction to HiSilicon V3 PMU drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.33.0

2 7

[PATCH openEuler-1.0-LTS v2] x86/irq: Plug vector setup race
by Jinjie Ruan 25 Sep '25

25 Sep '25

From: Thomas Gleixner <tglx(a)linutronix.de> mainline inclusion from mainline-v6.17-rc1 commit ce0b5eedcb753697d43f61dd2e27d68eb5d3150f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICZARI Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ce0b5eedcb753697d43f61dd2e27d68eb5d3150f upstream. Hogan reported a vector setup race, which overwrites the interrupt descriptor in the per CPU vector array resulting in a disfunctional device. CPU0 CPU1 interrupt is raised in APIC IRR but not handled free_irq() per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; request_irq() common_interrupt() d = this_cpu_read(vector_irq[vector]); per_cpu(vector_irq, CPU1)[vector] = desc; if (d == VECTOR_SHUTDOWN) this_cpu_write(vector_irq[vector], VECTOR_UNUSED); free_irq() cannot observe the pending vector in the CPU1 APIC as there is no way to query the remote CPUs APIC IRR. This requires that request_irq() uses the same vector/CPU as the one which was freed, but this also can be triggered by a spurious interrupt. Interestingly enough this problem managed to be hidden for more than a decade. Prevent this by reevaluating vector_irq under the vector lock, which is held by the interrupt activation code when vector_irq is updated. To avoid ifdeffery or IS_ENABLED() nonsense, move the [un]lock_vector_lock() declarations out under the CONFIG_IRQ_DOMAIN_HIERARCHY guard as it's only provided when CONFIG_X86_LOCAL_APIC=y. The current CONFIG_IRQ_DOMAIN_HIERARCHY guard is selected by CONFIG_X86_LOCAL_APIC, but can also be selected by other parts of the Kconfig system, which makes 32-bit UP builds with CONFIG_X86_LOCAL_APIC=n fail. Can we just get rid of this !APIC nonsense once and forever? Fixes: 9345005f4eed ("x86/irq: Fix do_IRQ() interrupt warning for cpu hotplug retriggered irqs") Cc: stable(a)vger.kernel.org#6.6.x Cc: gregkh(a)linuxfoundation.org Reported-by: Hogan Wang <hogan.wang(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Hogan Wang <hogan.wang(a)huawei.com> Link: https://lore.kernel.org/all/draft-87ikjhrhhh.ffs@tglx [ Conflicts in arch/x86/kernel/irq.c because call_irq_handler() has been refactored to do apic_eoi() according to the return value. Conflicts in arch/x86/include/asm/hw_irq.h because (un)lock_vector_lock() are already controlled by CONFIG_X86_LOCAL_APIC. ] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/irq.c | 68 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 55 insertions(+), 13 deletions(-) diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index a975246074b5..a6b400b89711 100644 --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -223,6 +223,60 @@ u64 arch_irq_stat(void) return sum; } +static struct irq_desc *reevaluate_vector(int vector) +{ + struct irq_desc * desc = __this_cpu_read(vector_irq[vector]); + + if (!IS_ERR_OR_NULL(desc)) + return desc; + + if (desc != VECTOR_RETRIGGERED && desc != VECTOR_SHUTDOWN) + pr_emerg_ratelimited("No irq handler for %d.%u\n", smp_processor_id(), vector); + else + __this_cpu_write(vector_irq[vector], VECTOR_UNUSED); + return NULL; +} + +static __always_inline bool call_irq_handler(int vector, struct pt_regs *regs) +{ + struct irq_desc * desc = __this_cpu_read(vector_irq[vector]); + + if (likely(!IS_ERR_OR_NULL(desc))) { + handle_irq(desc, regs); + return true: + } + + /* + * Reevaluate with vector_lock held to prevent a race against + * request_irq() setting up the vector: + * + * CPU0 CPU1 + * interrupt is raised in APIC IRR + * but not handled + * free_irq() + * per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; + * + * request_irq() common_interrupt() + * d = this_cpu_read(vector_irq[vector]); + * + * per_cpu(vector_irq, CPU1)[vector] = desc; + * + * if (d == VECTOR_SHUTDOWN) + * this_cpu_write(vector_irq[vector], VECTOR_UNUSED); + * + * This requires that the same vector on the same target CPU is + * handed out or that a spurious interrupt hits that CPU/vector. + */ + lock_vector_lock(); + desc = reevaluate_vector(vector); + unlock_vector_lock(); + + if (!desc) + return false; + + handle_irq(desc, regs); + return true; +} /* * do_IRQ handles all normal device IRQ's (the special @@ -232,7 +286,6 @@ u64 arch_irq_stat(void) __visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs) { struct pt_regs *old_regs = set_irq_regs(regs); - struct irq_desc * desc; /* high bit used in ret_from_ code */ unsigned vector = ~regs->orig_ax; @@ -241,20 +294,9 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs) /* entering_irq() tells RCU that we're not quiescent. Check it. */ RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU"); - desc = __this_cpu_read(vector_irq[vector]); - - if (!handle_irq(desc, regs)) { + if (unlikely(!call_irq_handler(vector, regs))) ack_APIC_irq(); - if (desc != VECTOR_RETRIGGERED && desc != VECTOR_SHUTDOWN) { - pr_emerg_ratelimited("%s: %d.%d No irq handler for vector\n", - __func__, smp_processor_id(), - vector); - } else { - __this_cpu_write(vector_irq[vector], VECTOR_UNUSED); - } - } - exiting_irq(); set_irq_regs(old_regs); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] x86/irq: Plug vector setup race
by Jinjie Ruan 25 Sep '25

25 Sep '25

From: Thomas Gleixner <tglx(a)linutronix.de> mainline inclusion from mainline-v6.17-rc1 commit ce0b5eedcb753697d43f61dd2e27d68eb5d3150f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICZARI Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ce0b5eedcb753697d43f61dd2e27d68eb5d3150f upstream. Hogan reported a vector setup race, which overwrites the interrupt descriptor in the per CPU vector array resulting in a disfunctional device. CPU0 CPU1 interrupt is raised in APIC IRR but not handled free_irq() per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; request_irq() common_interrupt() d = this_cpu_read(vector_irq[vector]); per_cpu(vector_irq, CPU1)[vector] = desc; if (d == VECTOR_SHUTDOWN) this_cpu_write(vector_irq[vector], VECTOR_UNUSED); free_irq() cannot observe the pending vector in the CPU1 APIC as there is no way to query the remote CPUs APIC IRR. This requires that request_irq() uses the same vector/CPU as the one which was freed, but this also can be triggered by a spurious interrupt. Interestingly enough this problem managed to be hidden for more than a decade. Prevent this by reevaluating vector_irq under the vector lock, which is held by the interrupt activation code when vector_irq is updated. To avoid ifdeffery or IS_ENABLED() nonsense, move the [un]lock_vector_lock() declarations out under the CONFIG_IRQ_DOMAIN_HIERARCHY guard as it's only provided when CONFIG_X86_LOCAL_APIC=y. The current CONFIG_IRQ_DOMAIN_HIERARCHY guard is selected by CONFIG_X86_LOCAL_APIC, but can also be selected by other parts of the Kconfig system, which makes 32-bit UP builds with CONFIG_X86_LOCAL_APIC=n fail. Can we just get rid of this !APIC nonsense once and forever? Fixes: 9345005f4eed ("x86/irq: Fix do_IRQ() interrupt warning for cpu hotplug retriggered irqs") Cc: stable(a)vger.kernel.org#6.6.x Cc: gregkh(a)linuxfoundation.org Reported-by: Hogan Wang <hogan.wang(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Hogan Wang <hogan.wang(a)huawei.com> Link: https://lore.kernel.org/all/draft-87ikjhrhhh.ffs@tglx [ Conflicts in arch/x86/kernel/irq.c because call_irq_handler() has been refactored to do apic_eoi() according to the return value. Conflicts in arch/x86/include/asm/hw_irq.h because (un)lock_vector_lock() are already controlled by CONFIG_X86_LOCAL_APIC. ] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/irq.c | 67 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 55 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index a975246074b5..77e1e1c4d1e6 100644 --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -223,6 +223,60 @@ u64 arch_irq_stat(void) return sum; } +static struct irq_desc *reevaluate_vector(int vector) +{ + struct irq_desc * desc = __this_cpu_read(vector_irq[vector]); + + if (!IS_ERR_OR_NULL(desc)) + return desc; + + if (desc != VECTOR_RETRIGGERED && desc != VECTOR_SHUTDOWN) + pr_emerg_ratelimited("No irq handler for %d.%u\n", smp_processor_id(), vector); + else + __this_cpu_write(vector_irq[vector], VECTOR_UNUSED); + return NULL; +} + +static __always_inline bool call_irq_handler(int vector, struct pt_regs *regs) +{ + struct irq_desc * desc = __this_cpu_read(vector_irq[vector]); + + if (likely(!IS_ERR_OR_NULL(desc))) { + handle_irq(desc, regs); + return true: + } + + /* + * Reevaluate with vector_lock held to prevent a race against + * request_irq() setting up the vector: + * + * CPU0 CPU1 + * interrupt is raised in APIC IRR + * but not handled + * free_irq() + * per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; + * + * request_irq() common_interrupt() + * d = this_cpu_read(vector_irq[vector]); + * + * per_cpu(vector_irq, CPU1)[vector] = desc; + * + * if (d == VECTOR_SHUTDOWN) + * this_cpu_write(vector_irq[vector], VECTOR_UNUSED); + * + * This requires that the same vector on the same target CPU is + * handed out or that a spurious interrupt hits that CPU/vector. + */ + lock_vector_lock(); + desc = reevaluate_vector(vector); + unlock_vector_lock(); + + if (!desc) + return false; + + handle_irq(desc, regs); + return true; +} /* * do_IRQ handles all normal device IRQ's (the special @@ -232,7 +286,6 @@ u64 arch_irq_stat(void) __visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs) { struct pt_regs *old_regs = set_irq_regs(regs); - struct irq_desc * desc; /* high bit used in ret_from_ code */ unsigned vector = ~regs->orig_ax; @@ -241,20 +294,10 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs) /* entering_irq() tells RCU that we're not quiescent. Check it. */ RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU"); - desc = __this_cpu_read(vector_irq[vector]); - if (!handle_irq(desc, regs)) { + if (unlikely(!call_irq_handler(vector, regs))) ack_APIC_irq(); - if (desc != VECTOR_RETRIGGERED && desc != VECTOR_SHUTDOWN) { - pr_emerg_ratelimited("%s: %d.%d No irq handler for vector\n", - __func__, smp_processor_id(), - vector); - } else { - __this_cpu_write(vector_irq[vector], VECTOR_UNUSED); - } - } - exiting_irq(); set_irq_regs(old_regs); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] x86/MCE: Always save CS register on AMD Zen IF Poison errors
by Bowen You 25 Sep '25

25 Sep '25

From: Yazen Ghannam <yazen.ghannam(a)amd.com> mainline inclusion from mainline-v6.12-rc1 commit 4240e2ebe67941ce2c4f5c866c3af4b5ac7a0c67 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICYQPT CVE: CVE-2023-53438 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed. There is no architecturally-defined method to determine this behavior. The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV]. Add a quirk to save the CS register for poison consumption from the IF unit banks. This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context. Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20230814200853.29258-1-yazen.ghannam@amd.com Conflicts: arch/x86/kernel/cpu/mce/core.c arch/x86/kernel/cpu/mce/internal.h [context conflict] Signed-off-by: Bowen You <youbowen2(a)huawei.com> --- arch/x86/kernel/cpu/mce/core.c | 26 ++++++++++++++++++++++++++ arch/x86/kernel/cpu/mce/internal.h | 5 ++++- 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c index 2b0fecdc137d..95e1b8228734 100644 --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -786,6 +786,26 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t *b) } EXPORT_SYMBOL_GPL(machine_check_poll); +/* + * Some Zen-based Instruction Fetch Units set EIPV=RIPV=0 on poison consumption + * errors. This means mce_gather_info() will not save the "ip" and "cs" registers. + * + * However, the context is still valid, so save the "cs" register for later use. + * + * The "ip" register is truly unknown, so don't save it or fixup EIPV/RIPV. + * + * The Instruction Fetch Unit is at MCA bank 1 for all affected systems. + */ +static __always_inline void quirk_zen_ifu(int bank, struct mce *m, struct pt_regs *regs) +{ + if (bank != 1) + return; + if (!(m->status & MCI_STATUS_POISON)) + return; + + m->cs = regs->cs; +} + /* * Do a quick check if any of the events requires a panic. * This decides if we keep the events around or clear them. @@ -805,6 +825,9 @@ static int mce_no_way_out(struct mce *m, char **msg, unsigned long *validp, if (quirk_no_way_out) quirk_no_way_out(i, m, regs); + if (mce_flags.zen_ifu_quirk) + quirk_zen_ifu(i, m, regs); + m->bank = i; if (mce_severity(m, mca_cfg.tolerant, &tmp, true) >= MCE_PANIC_SEVERITY) { mce_read_aux(m, i); @@ -1634,6 +1657,9 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 *c) if (c->x86 == 0x15 && c->x86_model <= 0xf) mce_flags.overflow_recov = 1; + if (c->x86 >= 0x17 && c->x86 <= 0x1A) + mce_flags.zen_ifu_quirk = 1; + } if (c->x86_vendor == X86_VENDOR_INTEL) { diff --git a/arch/x86/kernel/cpu/mce/internal.h b/arch/x86/kernel/cpu/mce/internal.h index 22e8aa8c8fe7..84e387bdcf22 100644 --- a/arch/x86/kernel/cpu/mce/internal.h +++ b/arch/x86/kernel/cpu/mce/internal.h @@ -162,7 +162,10 @@ struct mce_vendor_flags { */ smca : 1, - __reserved_0 : 61; + /* Zen IFU quirk */ + zen_ifu_quirk : 1, + + __reserved_0 : 60; }; extern struct mce_vendor_flags mce_flags; -- 2.34.1

2 1

[PATCH OLK-5.10] x86/MCE: Always save CS register on AMD Zen IF Poison errors
by Bowen You 25 Sep '25

25 Sep '25

From: Yazen Ghannam <yazen.ghannam(a)amd.com> mainline inclusion from mainline-v6.12-rc1 commit 4240e2ebe67941ce2c4f5c866c3af4b5ac7a0c67 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICYQPT CVE: CVE-2023-53438 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed. There is no architecturally-defined method to determine this behavior. The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV]. Add a quirk to save the CS register for poison consumption from the IF unit banks. This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context. Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20230814200853.29258-1-yazen.ghannam@amd.com Conflicts: arch/x86/kernel/cpu/mce/core.c arch/x86/kernel/cpu/mce/internal.h [context conflict] Signed-off-by: Bowen You <youbowen2(a)huawei.com> --- arch/x86/kernel/cpu/mce/core.c | 26 ++++++++++++++++++++++++++ arch/x86/kernel/cpu/mce/internal.h | 5 ++++- 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c index 497ff1901d9d..0ba4f59ec77c 100644 --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -841,6 +841,26 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t *b) } EXPORT_SYMBOL_GPL(machine_check_poll); +/* + * Some Zen-based Instruction Fetch Units set EIPV=RIPV=0 on poison consumption + * errors. This means mce_gather_info() will not save the "ip" and "cs" registers. + * + * However, the context is still valid, so save the "cs" register for later use. + * + * The "ip" register is truly unknown, so don't save it or fixup EIPV/RIPV. + * + * The Instruction Fetch Unit is at MCA bank 1 for all affected systems. + */ +static __always_inline void quirk_zen_ifu(int bank, struct mce *m, struct pt_regs *regs) +{ + if (bank != 1) + return; + if (!(m->status & MCI_STATUS_POISON)) + return; + + m->cs = regs->cs; +} + /* * Do a quick check if any of the events requires a panic. * This decides if we keep the events around or clear them. @@ -860,6 +880,9 @@ static int mce_no_way_out(struct mce *m, char **msg, unsigned long *validp, if (quirk_no_way_out) quirk_no_way_out(i, m, regs); + if (mce_flags.zen_ifu_quirk) + quirk_zen_ifu(i, m, regs); + m->bank = i; if (mce_severity(m, regs, mca_cfg.tolerant, &tmp, true) >= MCE_PANIC_SEVERITY) { mce_read_aux(m, i); @@ -1808,6 +1831,9 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 *c) if (c->x86 == 0x15 && c->x86_model <= 0xf) mce_flags.overflow_recov = 1; + if (c->x86 >= 0x17 && c->x86 <= 0x1A) + mce_flags.zen_ifu_quirk = 1; + } if (c->x86_vendor == X86_VENDOR_INTEL) { diff --git a/arch/x86/kernel/cpu/mce/internal.h b/arch/x86/kernel/cpu/mce/internal.h index 3a485c0d5791..1fd9ec69fffc 100644 --- a/arch/x86/kernel/cpu/mce/internal.h +++ b/arch/x86/kernel/cpu/mce/internal.h @@ -160,10 +160,13 @@ struct mce_vendor_flags { */ smca : 1, + /* Zen IFU quirk */ + zen_ifu_quirk : 1, + /* AMD-style error thresholding banks present. */ amd_threshold : 1, - __reserved_0 : 60; + __reserved_0 : 59; }; extern struct mce_vendor_flags mce_flags; -- 2.34.1

2 1

[PATCH OLK-6.6] ubsan: Fix incorrect hand-side used in handle
by Xiaomeng Zhang 25 Sep '25

25 Sep '25

From: Junhui Pei <paradoxskin233(a)gmail.com> mainline inclusion from mainline-v6.17-rc4 commit ae91aea2d2265c88dbed65a07bbaf3c133fe970c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICZMWA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- __ubsan_handle_divrem_overflow() incorrectly uses the RHS to report. It always reports the same log: division of -1 by -1. But it should report division of LHS by -1. Signed-off-by: Junhui Pei <paradoxskin233(a)gmail.com> Fixes: c6d308534aef ("UBSAN: run-time undefined behavior sanity checker") Link: https://lore.kernel.org/r/20250602153841.62935-1-paradoxskin233@gmail.com Signed-off-by: Kees Cook <kees(a)kernel.org> Conflicts: lib/ubsan.c [The conflicts were due to some minor issue.] Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13(a)huawei.com> --- lib/ubsan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/ubsan.c b/lib/ubsan.c index 3f90810f9f42..15e58f90bf31 100644 --- a/lib/ubsan.c +++ b/lib/ubsan.c @@ -226,18 +226,18 @@ static void ubsan_epilogue(void) void __ubsan_handle_divrem_overflow(void *_data, void *lhs, void *rhs) { struct overflow_data *data = _data; - char rhs_val_str[VALUE_LENGTH]; + char lhs_val_str[VALUE_LENGTH]; if (suppress_report(&data->location)) return; ubsan_prologue(&data->location, "division-overflow"); - val_to_string(rhs_val_str, sizeof(rhs_val_str), data->type, rhs); + val_to_string(lhs_val_str, sizeof(lhs_val_str), data->type, lhs); if (type_is_signed(data->type) && get_signed_val(data->type, rhs) == -1) pr_err("division of %s by -1 cannot be represented in type %s\n", - rhs_val_str, data->type->type_name); + lhs_val_str, data->type->type_name); else pr_err("division by zero\n"); -- 2.34.1

2 1

[PATCH OLK-5.10] ubsan: Fix incorrect hand-side used in handle
by Xiaomeng Zhang 25 Sep '25

25 Sep '25

From: Junhui Pei <paradoxskin233(a)gmail.com> mainline inclusion from mainline-v6.17-rc4 commit ae91aea2d2265c88dbed65a07bbaf3c133fe970c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICZMWA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- __ubsan_handle_divrem_overflow() incorrectly uses the RHS to report. It always reports the same log: division of -1 by -1. But it should report division of LHS by -1. Signed-off-by: Junhui Pei <paradoxskin233(a)gmail.com> Fixes: c6d308534aef ("UBSAN: run-time undefined behavior sanity checker") Link: https://lore.kernel.org/r/20250602153841.62935-1-paradoxskin233@gmail.com Signed-off-by: Kees Cook <kees(a)kernel.org> Conflicts: lib/ubsan.c [The conflicts were due to some minor issue.] Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13(a)huawei.com> --- lib/ubsan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/ubsan.c b/lib/ubsan.c index ee14c46cac89..12c7baa422d7 100644 --- a/lib/ubsan.c +++ b/lib/ubsan.c @@ -225,18 +225,18 @@ EXPORT_SYMBOL(__ubsan_handle_negate_overflow); void __ubsan_handle_divrem_overflow(void *_data, void *lhs, void *rhs) { struct overflow_data *data = _data; - char rhs_val_str[VALUE_LENGTH]; + char lhs_val_str[VALUE_LENGTH]; if (suppress_report(&data->location)) return; ubsan_prologue(&data->location, "division-overflow"); - val_to_string(rhs_val_str, sizeof(rhs_val_str), data->type, rhs); + val_to_string(lhs_val_str, sizeof(lhs_val_str), data->type, lhs); if (type_is_signed(data->type) && get_signed_val(data->type, rhs) == -1) pr_err("division of %s by -1 cannot be represented in type %s\n", - rhs_val_str, data->type->type_name); + lhs_val_str, data->type->type_name); else pr_err("division by zero\n"); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] ubsan: Fix incorrect hand-side used in handle
by Xiaomeng Zhang 25 Sep '25

25 Sep '25

From: Junhui Pei <paradoxskin233(a)gmail.com> mainline inclusion from mainline-v6.17-rc4 commit ae91aea2d2265c88dbed65a07bbaf3c133fe970c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICZMWA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- __ubsan_handle_divrem_overflow() incorrectly uses the RHS to report. It always reports the same log: division of -1 by -1. But it should report division of LHS by -1. Signed-off-by: Junhui Pei <paradoxskin233(a)gmail.com> Fixes: c6d308534aef ("UBSAN: run-time undefined behavior sanity checker") Link: https://lore.kernel.org/r/20250602153841.62935-1-paradoxskin233@gmail.com Signed-off-by: Kees Cook <kees(a)kernel.org> Conflicts: lib/ubsan.c [The conflicts were due to some minor issue.] Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13(a)huawei.com> --- lib/ubsan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/ubsan.c b/lib/ubsan.c index 1e9e2ab25539..92592f343ef3 100644 --- a/lib/ubsan.c +++ b/lib/ubsan.c @@ -239,18 +239,18 @@ void __ubsan_handle_divrem_overflow(struct overflow_data *data, void *lhs, void *rhs) { unsigned long flags; - char rhs_val_str[VALUE_LENGTH]; + char lhs_val_str[VALUE_LENGTH]; if (suppress_report(&data->location)) return; ubsan_prologue(&data->location, &flags); - val_to_string(rhs_val_str, sizeof(rhs_val_str), data->type, rhs); + val_to_string(lhs_val_str, sizeof(lhs_val_str), data->type, rhs); if (type_is_signed(data->type) && get_signed_val(data->type, rhs) == -1) pr_err("division of %s by -1 cannot be represented in type %s\n", - rhs_val_str, data->type->type_name); + lhs_val_str, data->type->type_name); else pr_err("division by zero\n"); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] firewire: net: fix use after free in fwnet_finish_incoming_packet()
by Xia Fukun 25 Sep '25

25 Sep '25

From: Zhang Shurong <zhang_shurong(a)foxmail.com> mainline inclusion from mainline-v6.17-rc7 commit 3ff256751a2853e1ffaa36958ff933ccc98c6cb5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICYQPN CVE: CVE-2023-53432 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The netif_rx() function frees the skb so we can't dereference it to save the skb->len. Signed-off-by: Zhang Shurong <zhang_shurong(a)foxmail.com> Link: https://lore.kernel.org/r/tencent_3B3D24B66ED66A6BB73CC0E63C6A14E45109@qq.c… Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Conflicts: drivers/firewire/net.c [Context differences.] Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/firewire/net.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c index bbabfca812bb..3bb5c9e75487 100644 --- a/drivers/firewire/net.c +++ b/drivers/firewire/net.c @@ -488,7 +488,7 @@ static int fwnet_finish_incoming_packet(struct net_device *net, bool is_broadcast, u16 ether_type) { struct fwnet_device *dev; - int status; + int status, len; __be64 guid; switch (ether_type) { @@ -545,13 +545,15 @@ static int fwnet_finish_incoming_packet(struct net_device *net, } skb->protocol = protocol; } + + len = skb->len; status = netif_rx(skb); if (status == NET_RX_DROP) { net->stats.rx_errors++; net->stats.rx_dropped++; } else { net->stats.rx_packets++; - net->stats.rx_bytes += skb->len; + net->stats.rx_bytes += len; } return 0; -- 2.34.1

2 1

[PATCH OLK-5.10] loop: Avoid updating block size under exclusive owner
by Zheng Qixing 25 Sep '25

25 Sep '25

From: Jan Kara <jack(a)suse.cz> mainline inclusion from mainline-v6.17-rc1 commit 7e49538288e523427beedd26993d446afef1a6fb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICWGGN CVE: CVE-2025-38709 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------ Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it. Reported-by: syzbot+01ef7a8da81a975e1ccd(a)syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack(a)suse.cz> Tested-by: syzbot+01ef7a8da81a975e1ccd(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20250711163202.19623-2-jack@suse.cz Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: drivers/block/loop.c [Context conflicts due to not merging commit 98ded54a3383, 473516b36193, ae0d40ff4964, 9423c653fe61, b38c8be255e8, b03732a9c0db and 1e1a9cecfab3.] Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/block/loop.c | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 8eefd1462c3f..35f40981a7b5 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1602,19 +1602,38 @@ static int loop_set_dio(struct loop_device *lo, unsigned long arg) return error; } -static int loop_set_block_size(struct loop_device *lo, unsigned long arg) +static int loop_set_block_size(struct loop_device *lo, fmode_t mode, + struct block_device *bdev, unsigned long arg) { + struct block_device *claimed_bdev = NULL; int err = 0; - if (lo->lo_state != Lo_bound) - return -ENXIO; + /* + * If we don't hold exclusive handle for the device, upgrade to it + * here to avoid changing device under exclusive owner. + */ + if (!(mode & FMODE_EXEC)) { + claimed_bdev = bdev->bd_contains; + err = bd_prepare_to_claim(bdev, claimed_bdev, loop_set_block_size); + if (err) + return err; + } + + err = mutex_lock_killable(&loop_ctl_mutex); + if (err) + goto abort_claim; + + if (lo->lo_state != Lo_bound) { + err = -ENXIO; + goto unlock; + } err = blk_validate_block_size(arg); if (err) - return err; + goto unlock; if (lo->lo_queue->limits.logical_block_size == arg) - return 0; + goto unlock; sync_blockdev(lo->lo_device); invalidate_bdev(lo->lo_device); @@ -1636,7 +1655,11 @@ static int loop_set_block_size(struct loop_device *lo, unsigned long arg) loop_update_dio(lo); out_unfreeze: blk_mq_unfreeze_queue(lo->lo_queue); - +unlock: + mutex_unlock(&loop_ctl_mutex); +abort_claim: + if (claimed_bdev) + bd_abort_claiming(bdev, claimed_bdev, loop_set_block_size); return err; } @@ -1655,9 +1678,6 @@ static int lo_simple_ioctl(struct loop_device *lo, unsigned int cmd, case LOOP_SET_DIRECT_IO: err = loop_set_dio(lo, arg); break; - case LOOP_SET_BLOCK_SIZE: - err = loop_set_block_size(lo, arg); - break; default: err = lo->ioctl ? lo->ioctl(lo, cmd, arg) : -EINVAL; } @@ -1714,9 +1734,12 @@ static int lo_ioctl(struct block_device *bdev, fmode_t mode, break; case LOOP_GET_STATUS64: return loop_get_status64(lo, argp); + case LOOP_SET_BLOCK_SIZE: + if (!(mode & FMODE_WRITE) && !capable(CAP_SYS_ADMIN)) + return -EPERM; + return loop_set_block_size(lo, mode, bdev, arg); case LOOP_SET_CAPACITY: case LOOP_SET_DIRECT_IO: - case LOOP_SET_BLOCK_SIZE: if (!(mode & FMODE_WRITE) && !capable(CAP_SYS_ADMIN)) return -EPERM; fallthrough; -- 2.39.2

2 1