- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 0/1] Fix CVE-2026-43262
by Hongbo Li 09 May '26

09 May '26

Fix CVE-2026-43262. Andreas Gruenbacher (1): gfs2: fiemap page fault fix fs/gfs2/inode.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) -- 2.34.1

2 2

[PATCH OLK-6.6 00/36] perf arm-spe: Support SPE new features
by Yushan Wang 09 May '26

09 May '26

From: Ying Jiang<jiangying44(a)h-partners.com> Anshuman Khandual (9): arm64: Handle BRBE booting requirements arm64/sysreg: Update register fields for ID_AA64MMFR0_EL1 arm64/sysreg: Add register fields for HDFGRTR2_EL2 arm64/sysreg: Add register fields for HDFGWTR2_EL2 arm64/sysreg: Add register fields for HFGITR2_EL2 arm64/sysreg: Add register fields for HFGRTR2_EL2 arm64/sysreg: Add register fields for HFGWTR2_EL2 arm64/sysreg: Update ID_DFR0_EL1 register fields arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9 Dave Martin (1): arm64: el2_setup.h: Rename some labels to be more diff-friendly James Clark (12): perf: arm_spe: Add format option for discard mode arm64: sysreg: Add new PMSFCR_EL1 fields and PMSDSFR_EL1 register perf: arm_spe: Support FEAT_SPEv1p4 filters perf: arm_spe: Add support for FEAT_SPE_EFT extended filtering arm64/boot: Factor out a macro to check SPE version arm64/boot: Enable EL2 requirements for SPE_FEAT_FDS KVM: arm64: Add trap configs for PMSDSFR_EL1 perf: Add perf_event_attr::config4 perf: arm_spe: Add support for filtering on data source tools headers UAPI: Sync linux/perf_event.h with the kernel sources perf tools: Add support for perf_event_attr::config4 perf docs: arm-spe: Document new SPE filtering features Leo Yan (1): perf: arm_spe: Expose event filter Marc Zyngier (5): KVM: arm64: Shave a few bytes from the EL2 idmap code arm64/sysreg: Allow a 'Mapping' descriptor for system registers arm64: sysreg: Add registers trapped by HDFG{R,W}TR2_EL2 KVM: arm64: nv: Add include containing the VNCR_EL2 offsets arm64: sysreg: Update PMSIDR_EL1 description Rob Herring (Arm) (4): arm64: el2_setup.h: Make __init_el2_fgt labels consistent, again perf/arm_pmuv3: Add PMUv3.9 per counter EL0 access control perf: arm_pmu: Use of_property_present() perf: arm_pmu: Remove event index to counter remapping Yushan Wang (4): Revert "arm64/boot: Enable EL2 requirements for BRBE" perf: Fix hw_metric event idx config perf: Keep event consistency of hw_metric events arm_pmuv3: hw_metric: Remove unnecessary check of event type Documentation/arch/arm64/booting.rst | 75 +++- arch/arm64/include/asm/el2_setup.h | 130 +++--- arch/arm64/include/asm/kvm_asm.h | 1 + arch/arm64/include/asm/sysreg.h | 19 +- arch/arm64/include/asm/vncr_mapping.h | 105 +++++ arch/arm64/kernel/asm-offsets.c | 1 + arch/arm64/kvm/emulate-nested.c | 1 + arch/arm64/kvm/hyp/nvhe/hyp-init.S | 52 ++- arch/arm64/kvm/pmu-emul.c | 6 +- arch/arm64/kvm/sys_regs.c | 1 + arch/arm64/tools/gen-sysreg.awk | 2 +- arch/arm64/tools/sysreg | 502 +++++++++++++++++++++- drivers/perf/apple_m1_cpu_pmu.c | 4 +- drivers/perf/arm_pmu.c | 11 +- drivers/perf/arm_pmu_platform.c | 2 +- drivers/perf/arm_pmuv3.c | 68 +-- drivers/perf/arm_spe_pmu.c | 170 +++++++- include/linux/perf/arm_pmu.h | 2 +- include/linux/perf/arm_pmuv3.h | 1 + include/uapi/linux/perf_event.h | 4 + tools/include/uapi/linux/perf_event.h | 2 + tools/perf/Documentation/perf-arm-spe.txt | 103 ++++- tools/perf/tests/parse-events.c | 14 +- tools/perf/util/parse-events.c | 11 + tools/perf/util/parse-events.h | 1 + tools/perf/util/parse-events.l | 1 + tools/perf/util/pmu.c | 3 + tools/perf/util/pmu.h | 1 + 28 files changed, 1098 insertions(+), 195 deletions(-) create mode 100644 arch/arm64/include/asm/vncr_mapping.h -- 2.33.0

2 37

[PATCH OLK-6.6] Revert "efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs"
by Xinyu Zheng 08 May '26

08 May '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8677 -------------------------------- This reverts commit b9c7bcaf7b0531bade10dfed2a453e0b40e62d20. This patch follow the latest UEFI/2.10 2.9A data structure specs description. In downstream CI environment, their Bios version just follow UEFI 2.8 verison, which has error type parse conflict. Since now all released BIOS version still following UEFI 2.8, revert this LTS patch to keep consistency. Fixes: b9c7bcaf7b05 ("efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs") Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/acpi/apei/ghes.c | 16 ++++------- drivers/firmware/efi/cper-arm.c | 50 +++++++++++++++++---------------- include/linux/cper.h | 10 +++---- 3 files changed, 37 insertions(+), 39 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 4c3dee093745..34ab844bd013 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -22,7 +22,6 @@ #include <linux/moduleparam.h> #include <linux/init.h> #include <linux/acpi.h> -#include <linux/bitfield.h> #include <linux/io.h> #include <linux/interrupt.h> #include <linux/timer.h> @@ -608,7 +607,6 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, { struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); int flags = sync ? MF_ACTION_REQUIRED : 0; - char error_type[120]; bool queued = false; int sec_sev, i; bool critical; @@ -627,8 +625,9 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, critical = ghes_armp_vendor_critical_error(err, sync); for (i = 0; i < err->err_info_num; i++) { struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; - bool is_cache = err_info->type & CPER_ARM_CACHE_ERROR; + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; /* * The field (err_info->error_info & BIT(26)) is fixed to set to @@ -642,15 +641,12 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, continue; } - cper_bits_to_str(error_type, sizeof(error_type), - FIELD_GET(CPER_ARM_ERR_TYPE_MASK, err_info->type), - cper_proc_error_type_strs, - ARRAY_SIZE(cper_proc_error_type_strs)); + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; pr_warn_ratelimited(FW_WARN GHES_PFX - "Unhandled processor error type 0x%02x: %s%s\n", - err_info->type, error_type, - (err_info->type & ~CPER_ARM_ERR_TYPE_MASK) ? " with reserved bit(s)" : ""); + "Unhandled processor error type: %s\n", + error_type); p += err_info->length; } diff --git a/drivers/firmware/efi/cper-arm.c b/drivers/firmware/efi/cper-arm.c index 52d18490b59e..eb7ee6af55f2 100644 --- a/drivers/firmware/efi/cper-arm.c +++ b/drivers/firmware/efi/cper-arm.c @@ -93,11 +93,15 @@ static void cper_print_arm_err_info(const char *pfx, u32 type, bool proc_context_corrupt, corrected, precise_pc, restartable_pc; bool time_out, access_mode; + /* If the type is unknown, bail. */ + if (type > CPER_ARM_MAX_TYPE) + return; + /* * Vendor type errors have error information values that are vendor * specific. */ - if (type & CPER_ARM_VENDOR_ERROR) + if (type == CPER_ARM_VENDOR_ERROR) return; if (error_info & CPER_ARM_ERR_VALID_TRANSACTION_TYPE) { @@ -112,38 +116,43 @@ static void cper_print_arm_err_info(const char *pfx, u32 type, if (error_info & CPER_ARM_ERR_VALID_OPERATION_TYPE) { op_type = ((error_info >> CPER_ARM_ERR_OPERATION_SHIFT) & CPER_ARM_ERR_OPERATION_MASK); - if (type & CPER_ARM_CACHE_ERROR) { + switch (type) { + case CPER_ARM_CACHE_ERROR: if (op_type < ARRAY_SIZE(arm_cache_err_op_strs)) { - printk("%scache error, operation type: %s\n", pfx, + printk("%soperation type: %s\n", pfx, arm_cache_err_op_strs[op_type]); } - } - if (type & CPER_ARM_TLB_ERROR) { + break; + case CPER_ARM_TLB_ERROR: if (op_type < ARRAY_SIZE(arm_tlb_err_op_strs)) { - printk("%sTLB error, operation type: %s\n", pfx, + printk("%soperation type: %s\n", pfx, arm_tlb_err_op_strs[op_type]); } - } - if (type & CPER_ARM_BUS_ERROR) { + break; + case CPER_ARM_BUS_ERROR: if (op_type < ARRAY_SIZE(arm_bus_err_op_strs)) { - printk("%sbus error, operation type: %s\n", pfx, + printk("%soperation type: %s\n", pfx, arm_bus_err_op_strs[op_type]); } + break; } } if (error_info & CPER_ARM_ERR_VALID_LEVEL) { level = ((error_info >> CPER_ARM_ERR_LEVEL_SHIFT) & CPER_ARM_ERR_LEVEL_MASK); - if (type & CPER_ARM_CACHE_ERROR) + switch (type) { + case CPER_ARM_CACHE_ERROR: printk("%scache level: %d\n", pfx, level); - - if (type & CPER_ARM_TLB_ERROR) + break; + case CPER_ARM_TLB_ERROR: printk("%sTLB level: %d\n", pfx, level); - - if (type & CPER_ARM_BUS_ERROR) + break; + case CPER_ARM_BUS_ERROR: printk("%saffinity level at which the bus error occurred: %d\n", pfx, level); + break; + } } if (error_info & CPER_ARM_ERR_VALID_PROC_CONTEXT_CORRUPT) { @@ -232,7 +241,6 @@ void cper_print_proc_arm(const char *pfx, struct cper_arm_err_info *err_info; struct cper_arm_ctx_info *ctx_info; char newpfx[64], infopfx[ARRAY_SIZE(newpfx) + 1]; - char error_type[120]; printk("%sMIDR: 0x%016llx\n", pfx, proc->midr); @@ -281,15 +289,9 @@ void cper_print_proc_arm(const char *pfx, newpfx); } - cper_bits_to_str(error_type, sizeof(error_type), - FIELD_GET(CPER_ARM_ERR_TYPE_MASK, err_info->type), - cper_proc_error_type_strs, - ARRAY_SIZE(cper_proc_error_type_strs)); - - printk("%serror_type: 0x%02x: %s%s\n", newpfx, err_info->type, - error_type, - (err_info->type & ~CPER_ARM_ERR_TYPE_MASK) ? " with reserved bit(s)" : ""); - + printk("%serror_type: %d, %s\n", newpfx, err_info->type, + err_info->type < ARRAY_SIZE(cper_proc_error_type_strs) ? + cper_proc_error_type_strs[err_info->type] : "unknown"); if (err_info->validation_bits & CPER_ARM_INFO_VALID_ERR_INFO) { printk("%serror_info: 0x%016llx\n", newpfx, err_info->error_info); diff --git a/include/linux/cper.h b/include/linux/cper.h index eb5c54814e76..e94724818bc2 100644 --- a/include/linux/cper.h +++ b/include/linux/cper.h @@ -274,11 +274,11 @@ enum { #define CPER_ARM_INFO_FLAGS_PROPAGATED BIT(2) #define CPER_ARM_INFO_FLAGS_OVERFLOW BIT(3) -#define CPER_ARM_ERR_TYPE_MASK GENMASK(4,1) -#define CPER_ARM_CACHE_ERROR BIT(1) -#define CPER_ARM_TLB_ERROR BIT(2) -#define CPER_ARM_BUS_ERROR BIT(3) -#define CPER_ARM_VENDOR_ERROR BIT(4) +#define CPER_ARM_CACHE_ERROR 0 +#define CPER_ARM_TLB_ERROR 1 +#define CPER_ARM_BUS_ERROR 2 +#define CPER_ARM_VENDOR_ERROR 3 +#define CPER_ARM_MAX_TYPE CPER_ARM_VENDOR_ERROR #define CPER_ARM_ERR_VALID_TRANSACTION_TYPE BIT(0) #define CPER_ARM_ERR_VALID_OPERATION_TYPE BIT(1) -- 2.34.1

2 1

[PATCH OLK-6.6] Revert "efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs"
by Xinyu Zheng 08 May '26

08 May '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8677 -------------------------------- This reverts commit b9c7bcaf7b0531bade10dfed2a453e0b40e62d20. This patch follow the latest UEFI/2.10 2.9A data structure specs description. In downstream CI environment, their Bios version just follow UEFI 2.8 verison, which has error type parse conflict. Since now all released BIOS version still following UEFI 2.8, revert this LTS patch to keep consistency. Fixes: b9c7bcaf7b05 ("[Backport] efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs") Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/acpi/apei/ghes.c | 16 ++++------- drivers/firmware/efi/cper-arm.c | 50 +++++++++++++++++---------------- include/linux/cper.h | 10 +++---- 3 files changed, 37 insertions(+), 39 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 4c3dee093745..34ab844bd013 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -22,7 +22,6 @@ #include <linux/moduleparam.h> #include <linux/init.h> #include <linux/acpi.h> -#include <linux/bitfield.h> #include <linux/io.h> #include <linux/interrupt.h> #include <linux/timer.h> @@ -608,7 +607,6 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, { struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata); int flags = sync ? MF_ACTION_REQUIRED : 0; - char error_type[120]; bool queued = false; int sec_sev, i; bool critical; @@ -627,8 +625,9 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, critical = ghes_armp_vendor_critical_error(err, sync); for (i = 0; i < err->err_info_num; i++) { struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p; - bool is_cache = err_info->type & CPER_ARM_CACHE_ERROR; + bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR); bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR); + const char *error_type = "unknown error"; /* * The field (err_info->error_info & BIT(26)) is fixed to set to @@ -642,15 +641,12 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, continue; } - cper_bits_to_str(error_type, sizeof(error_type), - FIELD_GET(CPER_ARM_ERR_TYPE_MASK, err_info->type), - cper_proc_error_type_strs, - ARRAY_SIZE(cper_proc_error_type_strs)); + if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs)) + error_type = cper_proc_error_type_strs[err_info->type]; pr_warn_ratelimited(FW_WARN GHES_PFX - "Unhandled processor error type 0x%02x: %s%s\n", - err_info->type, error_type, - (err_info->type & ~CPER_ARM_ERR_TYPE_MASK) ? " with reserved bit(s)" : ""); + "Unhandled processor error type: %s\n", + error_type); p += err_info->length; } diff --git a/drivers/firmware/efi/cper-arm.c b/drivers/firmware/efi/cper-arm.c index 52d18490b59e..eb7ee6af55f2 100644 --- a/drivers/firmware/efi/cper-arm.c +++ b/drivers/firmware/efi/cper-arm.c @@ -93,11 +93,15 @@ static void cper_print_arm_err_info(const char *pfx, u32 type, bool proc_context_corrupt, corrected, precise_pc, restartable_pc; bool time_out, access_mode; + /* If the type is unknown, bail. */ + if (type > CPER_ARM_MAX_TYPE) + return; + /* * Vendor type errors have error information values that are vendor * specific. */ - if (type & CPER_ARM_VENDOR_ERROR) + if (type == CPER_ARM_VENDOR_ERROR) return; if (error_info & CPER_ARM_ERR_VALID_TRANSACTION_TYPE) { @@ -112,38 +116,43 @@ static void cper_print_arm_err_info(const char *pfx, u32 type, if (error_info & CPER_ARM_ERR_VALID_OPERATION_TYPE) { op_type = ((error_info >> CPER_ARM_ERR_OPERATION_SHIFT) & CPER_ARM_ERR_OPERATION_MASK); - if (type & CPER_ARM_CACHE_ERROR) { + switch (type) { + case CPER_ARM_CACHE_ERROR: if (op_type < ARRAY_SIZE(arm_cache_err_op_strs)) { - printk("%scache error, operation type: %s\n", pfx, + printk("%soperation type: %s\n", pfx, arm_cache_err_op_strs[op_type]); } - } - if (type & CPER_ARM_TLB_ERROR) { + break; + case CPER_ARM_TLB_ERROR: if (op_type < ARRAY_SIZE(arm_tlb_err_op_strs)) { - printk("%sTLB error, operation type: %s\n", pfx, + printk("%soperation type: %s\n", pfx, arm_tlb_err_op_strs[op_type]); } - } - if (type & CPER_ARM_BUS_ERROR) { + break; + case CPER_ARM_BUS_ERROR: if (op_type < ARRAY_SIZE(arm_bus_err_op_strs)) { - printk("%sbus error, operation type: %s\n", pfx, + printk("%soperation type: %s\n", pfx, arm_bus_err_op_strs[op_type]); } + break; } } if (error_info & CPER_ARM_ERR_VALID_LEVEL) { level = ((error_info >> CPER_ARM_ERR_LEVEL_SHIFT) & CPER_ARM_ERR_LEVEL_MASK); - if (type & CPER_ARM_CACHE_ERROR) + switch (type) { + case CPER_ARM_CACHE_ERROR: printk("%scache level: %d\n", pfx, level); - - if (type & CPER_ARM_TLB_ERROR) + break; + case CPER_ARM_TLB_ERROR: printk("%sTLB level: %d\n", pfx, level); - - if (type & CPER_ARM_BUS_ERROR) + break; + case CPER_ARM_BUS_ERROR: printk("%saffinity level at which the bus error occurred: %d\n", pfx, level); + break; + } } if (error_info & CPER_ARM_ERR_VALID_PROC_CONTEXT_CORRUPT) { @@ -232,7 +241,6 @@ void cper_print_proc_arm(const char *pfx, struct cper_arm_err_info *err_info; struct cper_arm_ctx_info *ctx_info; char newpfx[64], infopfx[ARRAY_SIZE(newpfx) + 1]; - char error_type[120]; printk("%sMIDR: 0x%016llx\n", pfx, proc->midr); @@ -281,15 +289,9 @@ void cper_print_proc_arm(const char *pfx, newpfx); } - cper_bits_to_str(error_type, sizeof(error_type), - FIELD_GET(CPER_ARM_ERR_TYPE_MASK, err_info->type), - cper_proc_error_type_strs, - ARRAY_SIZE(cper_proc_error_type_strs)); - - printk("%serror_type: 0x%02x: %s%s\n", newpfx, err_info->type, - error_type, - (err_info->type & ~CPER_ARM_ERR_TYPE_MASK) ? " with reserved bit(s)" : ""); - + printk("%serror_type: %d, %s\n", newpfx, err_info->type, + err_info->type < ARRAY_SIZE(cper_proc_error_type_strs) ? + cper_proc_error_type_strs[err_info->type] : "unknown"); if (err_info->validation_bits & CPER_ARM_INFO_VALID_ERR_INFO) { printk("%serror_info: 0x%016llx\n", newpfx, err_info->error_info); diff --git a/include/linux/cper.h b/include/linux/cper.h index eb5c54814e76..e94724818bc2 100644 --- a/include/linux/cper.h +++ b/include/linux/cper.h @@ -274,11 +274,11 @@ enum { #define CPER_ARM_INFO_FLAGS_PROPAGATED BIT(2) #define CPER_ARM_INFO_FLAGS_OVERFLOW BIT(3) -#define CPER_ARM_ERR_TYPE_MASK GENMASK(4,1) -#define CPER_ARM_CACHE_ERROR BIT(1) -#define CPER_ARM_TLB_ERROR BIT(2) -#define CPER_ARM_BUS_ERROR BIT(3) -#define CPER_ARM_VENDOR_ERROR BIT(4) +#define CPER_ARM_CACHE_ERROR 0 +#define CPER_ARM_TLB_ERROR 1 +#define CPER_ARM_BUS_ERROR 2 +#define CPER_ARM_VENDOR_ERROR 3 +#define CPER_ARM_MAX_TYPE CPER_ARM_VENDOR_ERROR #define CPER_ARM_ERR_VALID_TRANSACTION_TYPE BIT(0) #define CPER_ARM_ERR_VALID_OPERATION_TYPE BIT(1) -- 2.34.1

2 1

[openEuler-1.0-LTS] pstore: ram_core: fix incorrect success return when vmap() fails
by Luo Gengkun 08 May '26

08 May '26

From: Ruipeng Qi <ruipengqi3(a)gmail.com> stable inclusion from stable-v5.10.252 commit d47234840aeb4182ed3ee795c578b1dfa9cbd25b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14671 CVE: CVE-2026-43124 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi <ruipengqi3(a)gmail.com> Link: https://patch.msgid.link/20260203020358.3315299-1-ruipengqi3@gmail.com Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- fs/pstore/ram_core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index 588392e6f531..749a9fa36b62 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -433,6 +433,13 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size, vaddr = vmap(pages, page_count, VM_MAP | VM_IOREMAP, prot); kfree(pages); + /* + * vmap() may fail and return NULL. Do not add the offset in this + * case, otherwise a NULL mapping would appear successful. + */ + if (!vaddr) + return NULL; + /* * Since vmap() uses page granularity, we must add the offset * into the page here, to get the byte granularity address -- 2.34.1

1 0

[PATCH OLK-6.6 0/2] Fix CVE-2026-31729
by Hongbo Li 08 May '26

08 May '26

Fix CVE-2026-31729. Nathan Rebello (2): usb: typec: ucsi: validate connector number in ucsi_notify_common() usb: typec: ucsi: skip connector validation before init drivers/usb/typec/ucsi/ucsi.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-6.6] atm: lec: fix use-after-free in sock_def_readable()
by Yi Yang 08 May '26

08 May '26

From: Deepanshu Kartikey <kartikey406(a)gmail.com> stable inclusion from stable-v6.6.134 commit b256d055da47258e63f8b40965f276c5f23d229a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14582 CVE: CVE-2026-43050 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 922814879542c2e397b0e9641fd36b8202a8e555 ] A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with "Connection to localhost closed by remote host", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with "make W=1 net/atm/lec.o" passes cleanly. Reported-by: syzbot+f50072212ab792c86925(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f50072212ab792c86925 Link: https://lore.kernel.org/all/20260309093614.502094-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20260309155908.508768-1-kartikey406@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- net/atm/lec.c | 72 +++++++++++++++++++++++++++++++++------------------ net/atm/lec.h | 2 +- 2 files changed, 48 insertions(+), 26 deletions(-) diff --git a/net/atm/lec.c b/net/atm/lec.c index b7fa48a9b720..e14b7ca8b17e 100644 --- a/net/atm/lec.c +++ b/net/atm/lec.c @@ -154,10 +154,19 @@ static void lec_handle_bridge(struct sk_buff *skb, struct net_device *dev) /* 0x01 is topology change */ priv = netdev_priv(dev); - atm_force_charge(priv->lecd, skb2->truesize); - sk = sk_atm(priv->lecd); - skb_queue_tail(&sk->sk_receive_queue, skb2); - sk->sk_data_ready(sk); + struct atm_vcc *vcc; + + rcu_read_lock(); + vcc = rcu_dereference(priv->lecd); + if (vcc) { + atm_force_charge(vcc, skb2->truesize); + sk = sk_atm(vcc); + skb_queue_tail(&sk->sk_receive_queue, skb2); + sk->sk_data_ready(sk); + } else { + dev_kfree_skb(skb2); + } + rcu_read_unlock(); } } #endif /* IS_ENABLED(CONFIG_BRIDGE) */ @@ -216,7 +225,7 @@ static netdev_tx_t lec_start_xmit(struct sk_buff *skb, int is_rdesc; pr_debug("called\n"); - if (!priv->lecd) { + if (!rcu_access_pointer(priv->lecd)) { pr_info("%s:No lecd attached\n", dev->name); dev->stats.tx_errors++; netif_stop_queue(dev); @@ -449,10 +458,19 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb) break; skb2->len = sizeof(struct atmlec_msg); skb_copy_to_linear_data(skb2, mesg, sizeof(*mesg)); - atm_force_charge(priv->lecd, skb2->truesize); - sk = sk_atm(priv->lecd); - skb_queue_tail(&sk->sk_receive_queue, skb2); - sk->sk_data_ready(sk); + struct atm_vcc *vcc; + + rcu_read_lock(); + vcc = rcu_dereference(priv->lecd); + if (vcc) { + atm_force_charge(vcc, skb2->truesize); + sk = sk_atm(vcc); + skb_queue_tail(&sk->sk_receive_queue, skb2); + sk->sk_data_ready(sk); + } else { + dev_kfree_skb(skb2); + } + rcu_read_unlock(); } } #endif /* IS_ENABLED(CONFIG_BRIDGE) */ @@ -468,23 +486,16 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb) static void lec_atm_close(struct atm_vcc *vcc) { - struct sk_buff *skb; struct net_device *dev = (struct net_device *)vcc->proto_data; struct lec_priv *priv = netdev_priv(dev); - priv->lecd = NULL; + rcu_assign_pointer(priv->lecd, NULL); + synchronize_rcu(); /* Do something needful? */ netif_stop_queue(dev); lec_arp_destroy(priv); - if (skb_peek(&sk_atm(vcc)->sk_receive_queue)) - pr_info("%s closing with messages pending\n", dev->name); - while ((skb = skb_dequeue(&sk_atm(vcc)->sk_receive_queue))) { - atm_return(vcc, skb->truesize); - dev_kfree_skb(skb); - } - pr_info("%s: Shut down!\n", dev->name); module_put(THIS_MODULE); } @@ -510,12 +521,14 @@ send_to_lecd(struct lec_priv *priv, atmlec_msg_type type, const unsigned char *mac_addr, const unsigned char *atm_addr, struct sk_buff *data) { + struct atm_vcc *vcc; struct sock *sk; struct sk_buff *skb; struct atmlec_msg *mesg; - if (!priv || !priv->lecd) + if (!priv || !rcu_access_pointer(priv->lecd)) return -1; + skb = alloc_skb(sizeof(struct atmlec_msg), GFP_ATOMIC); if (!skb) return -1; @@ -532,18 +545,27 @@ send_to_lecd(struct lec_priv *priv, atmlec_msg_type type, if (atm_addr) memcpy(&mesg->content.normal.atm_addr, atm_addr, ATM_ESA_LEN); - atm_force_charge(priv->lecd, skb->truesize); - sk = sk_atm(priv->lecd); + rcu_read_lock(); + vcc = rcu_dereference(priv->lecd); + if (!vcc) { + rcu_read_unlock(); + kfree_skb(skb); + return -1; + } + + atm_force_charge(vcc, skb->truesize); + sk = sk_atm(vcc); skb_queue_tail(&sk->sk_receive_queue, skb); sk->sk_data_ready(sk); if (data != NULL) { pr_debug("about to send %d bytes of data\n", data->len); - atm_force_charge(priv->lecd, data->truesize); + atm_force_charge(vcc, data->truesize); skb_queue_tail(&sk->sk_receive_queue, data); sk->sk_data_ready(sk); } + rcu_read_unlock(); return 0; } @@ -618,7 +640,7 @@ static void lec_push(struct atm_vcc *vcc, struct sk_buff *skb) atm_return(vcc, skb->truesize); if (*(__be16 *) skb->data == htons(priv->lecid) || - !priv->lecd || !(dev->flags & IFF_UP)) { + !rcu_access_pointer(priv->lecd) || !(dev->flags & IFF_UP)) { /* * Probably looping back, or if lecd is missing, * lecd has gone down @@ -753,12 +775,12 @@ static int lecd_attach(struct atm_vcc *vcc, int arg) priv = netdev_priv(dev_lec[i]); } else { priv = netdev_priv(dev_lec[i]); - if (priv->lecd) + if (rcu_access_pointer(priv->lecd)) return -EADDRINUSE; } lec_arp_init(priv); priv->itfnum = i; /* LANE2 addition */ - priv->lecd = vcc; + rcu_assign_pointer(priv->lecd, vcc); vcc->dev = &lecatm_dev; vcc_insert_socket(sk_atm(vcc)); diff --git a/net/atm/lec.h b/net/atm/lec.h index be0e2667bd8c..ec85709bf818 100644 --- a/net/atm/lec.h +++ b/net/atm/lec.h @@ -91,7 +91,7 @@ struct lec_priv { */ spinlock_t lec_arp_lock; struct atm_vcc *mcast_vcc; /* Default Multicast Send VCC */ - struct atm_vcc *lecd; + struct atm_vcc __rcu *lecd; struct delayed_work lec_arp_work; /* C10 */ unsigned int maximum_unknown_frame_count; /* -- 2.25.1

2 1

[PATCH OLK-6.6 v10 0/5] SMT QOS
by Jinjie Ruan 08 May '26

08 May '26

Cloud Service Provider deploy Best-Effort and Latency Sensitive tasks on the same physical core to maximize the resource utilization. We observe the LS task needs more cycles to complete the same workload due to the Microarchitectural resource contention. This feature control the instruction throughput of BE task into pipeline, so that the other SMT running LS task could occupy more uarch resources to reach better IPC. First split out QOS_LABEL from QOS_SCHED for SMT QoS reuse. The test results on 920G: +-------------------------------------------------------------+ | | 基线 | 混布基线 | SMT QoS | | sched_wfi_timeout_us | \ | \ | 50 | | sched_smt_offline_util_pct | \ | \ | 50 | | P99 | 0.201 | 0.292 | 0.212 | | CPU utilization | 29.3% | 67.00% | 63.30% | | P99 regression percentage | \ | 45.27% | 5.47% | +-------------------------------------------------------------+ Changes in v10: - Decouple QOS_SCHED_SMT_EXPELLER and QOS_SCHED scheduling logic with SMT_QOS. - Some cleanup. Changes in v9: - Also use SMT sibling CPU utilization NUMA level watermark for offline task cpu select to improve the 920G CPU utilization. Chanegs in v8: - Use SMT sibling CPU utilization NUMA level watermark instead of src cpu offline tasks migrate watermark on every load balance. Changes in v7: - Fix the prefer_cpu and select_cpus save/restore. - Extract can_smt_qos_migrate_task() helper from can_migrate_task(). - Update the names. - Update the arch code and remove the pmu code. - Add some comment. Changes in v6: - Rename QOS_LABEL to QOS_LEVEL. - Rename USER_WFXT to SMT_QOS. - Rename TAG_PULL to SMT_TAG_PULL. - Adjust the select cpu code which depends on QOS_SCHED_DYNAMIC_AFFINITY. - Distribute offline tasks to SMT sibling cores based on the configured proportion move to a separate patch. - Use cpumask_t for even_cpu_mask. - smt_throttle move to the arch patch. - pmu_smt_update_status() -> smt_update_qos_level(). - >> smt_task_imbalance instead of / 1000. - Remove the limit for odd -> even load balance, which solve the one NUMA load very high problem. - Rebased on the newest OLK-6.6 code. - Fix the build issue for QOS_LEVEL selected but CGROUP_SCHED or CFS_BANDWIDTH not selected. Jinjie Ruan (5): sched: Split out QOS_LEVEL from QOS_SCHED for reuse sched: Add qos_sched_enabled() helper for future expansion sched/fair: Add SMT QoS sched core code arm64: Add arch code for SMT QoS config: Enable SMT_QOS arch/arm64/Kconfig.turbo | 17 ++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/cpufeature.h | 5 + arch/arm64/include/asm/xint.h | 15 ++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/entry-common.c | 16 ++ arch/arm64/kernel/entry.S | 14 +- arch/arm64/kernel/smp.c | 23 ++ arch/arm64/kernel/smt_qos.c | 84 +++++++ arch/arm64/kernel/xcall/entry.S | 78 +++++++ drivers/irqchip/irq-gic-v3.c | 43 ++++ include/linux/sched.h | 20 ++ init/Kconfig | 5 + kernel/sched/core.c | 20 +- kernel/sched/fair.c | 289 ++++++++++++++++++++++++- kernel/sched/features.h | 4 + kernel/sched/sched.h | 18 +- 17 files changed, 618 insertions(+), 35 deletions(-) create mode 100644 arch/arm64/include/asm/xint.h create mode 100644 arch/arm64/kernel/smt_qos.c -- 2.34.1

2 6

[PATCH OLK-6.6] mm/numa_remote: avoid numa_remote lock when onlining pre-onlined memory
by Jinjiang Tu 08 May '26

08 May '26

hulk inclusion category: performance bugzilla: https://atomgit.com/openeuler/kernel/issues/9122 ---------------------------------------- When onlining pre-onlined memory, numa_remote lock is held to check if the memory range is pre-onlined. However, it may lead to unstable performance when the lock is contended. So, don't check it in add_memory_remote(), only check it in numa_remote_undo_fake_online(). Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/base/numa_remote.c | 56 ++++++++++++++++---------------------- 1 file changed, 23 insertions(+), 33 deletions(-) diff --git a/drivers/base/numa_remote.c b/drivers/base/numa_remote.c index f53d1dcab2ce..fed37dc20391 100644 --- a/drivers/base/numa_remote.c +++ b/drivers/base/numa_remote.c @@ -30,6 +30,7 @@ static nodemask_t numa_nodes_remote; struct undo_fake_online_control { u64 start; u64 size; + int nid; struct llist_node llist; }; @@ -283,17 +284,14 @@ static void numa_remote_online_pages(unsigned long start_pfn, unsigned long end_ * Undo fake-online a remote node. Have to be called in preonline mode then * the memory on the node can be allocated. */ -static int __ref numa_remote_undo_fake_online(u64 start, u64 size) +static int __ref numa_remote_undo_fake_online(u64 start, u64 size, int nid) { unsigned long start_pfn = PFN_DOWN(start); unsigned long end_pfn = PFN_DOWN(start + size); unsigned long nr_pages = end_pfn - start_pfn; - struct zone *zone; - int nid; int ret = 0; mem_hotplug_begin(); - /* Re-check whether all memory block are pre-online. */ if (!check_memory_block_pre_online(start, size, true)) { ret = -EINVAL; goto out; @@ -304,8 +302,6 @@ static int __ref numa_remote_undo_fake_online(u64 start, u64 size) goto out; } - zone = page_zone(phys_to_page(start)); - nid = zone_to_nid(zone); if (!check_memory_block_nid(start, size, nid)) { ret = -EINVAL; goto out; @@ -328,6 +324,8 @@ static int __ref numa_remote_undo_fake_online(u64 start, u64 size) out: atomic_long_add(-nr_pages, &undo_fake_online_pages_node[nid]); mem_hotplug_done(); + if (unlikely(ret)) + pr_warn("online memory [%llx, %llx) failed: %d\n", start, start + size, ret); return ret; } @@ -362,7 +360,7 @@ static void undo_fake_online_work_fn(struct work_struct *work) node = node->next; mutex_lock(&numa_remote_lock); - numa_remote_undo_fake_online(uic->start, uic->size); + numa_remote_undo_fake_online(uic->start, uic->size, uic->nid); mutex_unlock(&numa_remote_lock); kfree(uic); } @@ -454,43 +452,37 @@ int add_memory_remote(int nid, u64 start, u64 size, int flags) if (flags == (MEMORY_KEEP_ISOLATED | MEMORY_DIRECT_ONLINE)) return NUMA_NO_NODE; - if (flags & (MEMORY_KEEP_ISOLATED | MEMORY_DIRECT_ONLINE)) { - numa_remote_wait_undo_fake_online(); - down_write(&numa_remote_state_lock); - } - mutex_lock(&numa_remote_lock); - - if (numa_remote_preonline_mode && !flags) { + /* Online pre-onlined memory. To avoid grabbing numa_rmeote + * lock and leading to unstable performance, don't check if + * [start, start + size) is pre-onelined, check it in the + * async work. + */ + if (!flags) { struct undo_fake_online_control *uic; if (check_hotplug_memory_range(start, size)) - goto out; - /* Check whether all memory block are pre-online. */ - if (!check_memory_block_pre_online(start, size, true)) - goto out; + return NUMA_NO_NODE; - real_nid = (nid == NUMA_NO_NODE) ? - page_to_nid(phys_to_page(start)) : nid; - if (!check_memory_block_nid(start, size, real_nid)) { - real_nid = NUMA_NO_NODE; - goto out; - } + if (nid == NUMA_NO_NODE) + return NUMA_NO_NODE; uic = kzalloc(sizeof(struct undo_fake_online_control), GFP_KERNEL); - if (!uic) { - real_nid = NUMA_NO_NODE; - goto out; - } + if (!uic) + return NUMA_NO_NODE; - atomic_long_add(size / PAGE_SIZE, &undo_fake_online_pages_node[real_nid]); + atomic_long_add(size / PAGE_SIZE, &undo_fake_online_pages_node[nid]); uic->start = start; uic->size = size; + uic->nid = nid; if (llist_add(&uic->llist, &undo_fake_online_list)) schedule_work(&undo_fake_online_work); - goto out; + return nid; } + numa_remote_wait_undo_fake_online(); + down_write(&numa_remote_state_lock); + mutex_lock(&numa_remote_lock); lock_device_hotplug(); real_nid = (nid == NUMA_NO_NODE) ? find_unused_remote_node() : nid; @@ -505,10 +497,8 @@ int add_memory_remote(int nid, u64 start, u64 size, int flags) unlock: unlock_device_hotplug(); -out: mutex_unlock(&numa_remote_lock); - if (flags & (MEMORY_KEEP_ISOLATED | MEMORY_DIRECT_ONLINE)) - up_write(&numa_remote_state_lock); + up_write(&numa_remote_state_lock); return real_nid; } EXPORT_SYMBOL_GPL(add_memory_remote); -- 2.43.0

2 1

[PATCH OLK-5.10 0/1] Revert "[cpufreq]Fix re-boost issue after hotplugging a CPU"
by Lifeng Zheng 08 May '26

08 May '26

From: Hongye Lin <linhongye(a)h-partners.com> driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8995 ---------------------------------------------------------------------- Lifeng Zheng (1): Revert "[cpufreq]Fix re-boost issue after hotplugging a CPU" drivers/cpufreq/cpufreq.c | 4 ---- 1 file changed, 4 deletions(-) -- 2.33.0

2 2

[PATCH OLK-5.10 0/1] cpufreq: conservative: Reset requested_freq on limits change
by Lifeng Zheng 08 May '26

08 May '26

From: Hongye Lin <linhongye(a)h-partners.com> mainline inclusion from mainline-v7.0-rc6 commit 6a28fb8cb28b9eb39a392e531d938a889eacafc5 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8993 CVE: NA Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… ---------------------------------------------------------------------- A recently reported issue highlighted that the cached requested_freq is not guaranteed to stay in sync with policy->cur. If the platform changes the actual CPU frequency after the governor sets one (e.g. due to platform-specific frequency scaling) and a re-sync occurs later, policy->cur may diverge from requested_freq. This can lead to incorrect behavior in the conservative governor. For example, the governor may assume the CPU is already running at the maximum frequency and skip further increases even though there is still headroom. Avoid this by resetting the cached requested_freq to policy->cur on detecting a change in policy limits. Viresh Kumar (1): cpufreq: conservative: Reset requested_freq on limits change drivers/cpufreq/cpufreq_conservative.c | 12 ++++++++++++ drivers/cpufreq/cpufreq_governor.c | 3 +++ drivers/cpufreq/cpufreq_governor.h | 1 + 3 files changed, 16 insertions(+) -- 2.33.0

2 2

[PATCH OLK-6.6 0/1] kvm: arm64: Add HIP13 cpu type definition for detecting virtualization features
by liqiqi 08 May '26

08 May '26

Add HIP13 cpu type for detecting whether IPIv and DVMBM are supported. liqiqi (1): kvm: arm64: Add HIP13 cpu type definition for detecting virtualization features arch/arm64/kvm/hisilicon/hisi_virt.c | 12 +++++++----- arch/arm64/kvm/hisilicon/hisi_virt.h | 1 + 2 files changed, 8 insertions(+), 5 deletions(-) -- 2.43.0

2 2

[PATCH OLK-5.10] bpf: Fix regsafe() for pointers to packet
by Pu Lehui 08 May '26

08 May '26

From: Alexei Starovoitov <ast(a)kernel.org> mainline inclusion from mainline-v7.0-rc7 commit a8502a79e832b861e99218cbd2d8f4312d62e225 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8900 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug. Fixes: 6d94e741a8ff ("bpf: Support for pointers beyond pkt_end.") Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Daniel Borkmann <daniel(a)iogearbox.net> Reviewed-by: Amery Hung <ameryhung(a)gmail.com> Acked-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://lore.kernel.org/bpf/20260331204228.26726-1-alexei.starovoitov@gmail… Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 13df8a2fc4d7..678a98e86398 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -9706,8 +9706,13 @@ static bool regsafe(struct bpf_verifier_env *env, struct bpf_reg_state *rold, * since someone could have accessed through (ptr - k), or * even done ptr -= k in a register, to get a safe access. */ - if (rold->range > rcur->range) + if (rold->range < 0 || rcur->range < 0) { + /* special case for [BEYOND|AT]_PKT_END */ + if (rold->range != rcur->range) + return false; + } else if (rold->range > rcur->range) { return false; + } /* If the offsets don't match, we can't trust our alignment; * nor can we be sure that we won't fall out of range. */ -- 2.34.1

2 1

[PATCH OLK-6.6] mm/userfaultfd: fix hugetlb fault mutex hash calculation
by Ze Zuo 08 May '26

08 May '26

From: Jianhui Zhou <jianhuizzzzz(a)gmail.com> mainline inclusion from mainline-v7.1-rc1 commit 0217c7fb4de4a40cee667eb21901f3204effe5ac category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14321 CVE: CVE-2026-31575 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the page index for hugetlb_fault_mutex_hash(). However, linear_page_index() returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash() expects the index in huge page units. This mismatch means that different addresses within the same huge page can produce different hash values, leading to the use of different mutexes for the same huge page. This can cause races between faulting threads, which can corrupt the reservation map and trigger the BUG_ON in resv_map_release(). Fix this by introducing hugetlb_linear_page_index(), which returns the page index in huge page granularity, and using it in place of linear_page_index(). Link: https://lkml.kernel.org/r/20260310110526.335749-1-jianhuizzzzz@gmail.com Fixes: a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c") Signed-off-by: Jianhui Zhou <jianhuizzzzz(a)gmail.com> Reported-by: syzbot+f525fd79634858f478e7(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f525fd79634858f478e7 Acked-by: SeongJae Park <sj(a)kernel.org> Reviewed-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Cc: Jane Chu <jane.chu(a)oracle.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: JonasZhou <JonasZhou(a)zhaoxin.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Peter Xu <peterx(a)redhat.com> Cc: SeongJae Park <sj(a)kernel.org> Cc: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: include/linux/hugetlb.h [Conflict due not to meger commit 4a25f995bd59("mm: hugetlb: directly pass order when allocate a hugetlb folio"), context conflict.] Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- include/linux/hugetlb.h | 17 +++++++++++++++++ mm/userfaultfd.c | 2 +- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index e4e243bad311..419f72303370 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -896,6 +896,23 @@ static inline unsigned huge_page_shift(struct hstate *h) return h->order + PAGE_SHIFT; } +/** + * hugetlb_linear_page_index() - linear_page_index() but in hugetlb + * page size granularity. + * @vma: the hugetlb VMA + * @address: the virtual address within the VMA + * + * Return: the page offset within the mapping in huge page units. + */ +static inline pgoff_t hugetlb_linear_page_index(struct vm_area_struct *vma, + unsigned long address) +{ + struct hstate *h = hstate_vma(vma); + + return ((address - vma->vm_start) >> huge_page_shift(h)) + + (vma->vm_pgoff >> huge_page_order(h)); +} + static inline bool hstate_is_gigantic(struct hstate *h) { return huge_page_order(h) > MAX_ORDER; diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 2c71a269a52c..53afe2e97bc1 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -468,7 +468,7 @@ static __always_inline ssize_t mfill_atomic_hugetlb( * in the case of shared pmds. fault mutex prevents * races with other faulting threads. */ - idx = linear_page_index(dst_vma, dst_addr); + idx = hugetlb_linear_page_index(dst_vma, dst_addr); mapping = dst_vma->vm_file->f_mapping; hash = hugetlb_fault_mutex_hash(mapping, idx); mutex_lock(&hugetlb_fault_mutex_table[hash]); -- 2.25.1

2 1

[PATCH OLK-6.6] EDAC/mc: Fix error path ordering in edac_mc_alloc()
by Ye Bin 07 May '26

07 May '26

From: "Borislav Petkov (AMD)" <bp(a)alien8.de> stable inclusion from stable-v6.6.135 commit d3de72e2a2b9ee3a57734c1c068823e41a707715 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14436 CVE: CVE-2026-31689 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 51520e03e70d6c73e33ee7cbe0319767d05764fe upstream. When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device's release function. However, the init ordering is wrong such that device_initialize() happens *after* the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called: MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: <TASK> edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ... Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used. This was found by Claude while reviewing another EDAC patch. Fixes: 0bbb265f7089 ("EDAC/mc: Get rid of silly one-shot struct allocation in edac_mc_alloc()") Reported-by: Claude Code:claude-opus-4.5 Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Cc: stable(a)kernel.org Link: https://patch.msgid.link/20260331121623.4871-1-bp@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/edac/edac_mc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c index 6faeb2ab3960..952ebd94e0ec 100644 --- a/drivers/edac/edac_mc.c +++ b/drivers/edac/edac_mc.c @@ -369,13 +369,13 @@ struct mem_ctl_info *edac_mc_alloc(unsigned int mc_num, if (!mci->layers) goto error; + mci->dev.release = mci_release; + device_initialize(&mci->dev); + mci->pvt_info = kzalloc(sz_pvt, GFP_KERNEL); if (!mci->pvt_info) goto error; - mci->dev.release = mci_release; - device_initialize(&mci->dev); - /* setup index and various internal pointers */ mci->mc_idx = mc_num; mci->tot_dimms = tot_dimms; -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] net: Fix CVE-2026-31518
by Dong Chenchen 07 May '26

07 May '26

Fix CVE-2026-31518 Sabrina Dubroca (1): esp: fix skb leak with espintcp and async crypto Steffen Klassert (1): xfrm: Fix the usage of skb->sk net/ipv4/esp4.c | 11 +++++++---- net/ipv6/esp6.c | 11 +++++++---- net/ipv6/xfrm6_output.c | 4 ++-- net/xfrm/xfrm_interface_core.c | 2 +- net/xfrm/xfrm_output.c | 7 ++++--- net/xfrm/xfrm_policy.c | 2 +- 6 files changed, 22 insertions(+), 15 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/2] net/sched: Fix CVE-2026-31421
by Dong Chenchen 07 May '26

07 May '26

Fix CVE-2026-31421 Davide Caratti (1): net/sched: cls_fw: fix NULL dereference of "old" filters before change() Xiang Mei (1): net/sched: cls_fw: fix NULL pointer dereference on shared blocks net/sched/cls_fw.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) -- 2.25.1

2 3

[PATCH OLK-5.10] x86/CPU: Fix FPDSS on Zen1
by Zhang Kunbo 07 May '26

07 May '26

From: "Borislav Petkov (AMD)" <bp(a)alien8.de> stable inclusion from stable-v5.10.253 commit ed7a3a246309ccc807238f1b4f159ee6d37ff9c4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14370 CVE: CVE-2026-31628 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e55d98e7756135f32150b9b8f75d580d0d4b2dd3 upstream. Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit. Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: arch/x86/kernel/cpu/amd.c [ context conflict] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/include/asm/msr-index.h | 3 +++ arch/x86/kernel/cpu/amd.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index a01922b0ed82..01175f84c89d 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -521,6 +521,9 @@ #define MSR_AMD64_DC_CFG 0xc0011022 #define MSR_AMD64_TW_CFG 0xc0011023 +#define MSR_AMD64_FP_CFG 0xc0011028 +#define MSR_AMD64_FP_CFG_ZEN1_DENORM_FIX_BIT 9 + #define MSR_AMD64_DE_CFG 0xc0011029 #define MSR_AMD64_DE_CFG_LFENCE_SERIALIZE_BIT 1 #define MSR_AMD64_DE_CFG_LFENCE_SERIALIZE BIT_ULL(MSR_AMD64_DE_CFG_LFENCE_SERIALIZE_BIT) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index cb66f17855dd..b9944748634e 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1041,6 +1041,9 @@ static void init_amd_zen1(struct cpuinfo_x86 *c) msr_clear_bit(MSR_K7_HWCR, MSR_K7_HWCR_IRPERF_EN_BIT); clear_cpu_cap(c, X86_FEATURE_IRPERF); } + + pr_notice_once("AMD Zen1 FPDSS bug detected, enabling mitigation.\n"); + msr_set_bit(MSR_AMD64_FP_CFG, MSR_AMD64_FP_CFG_ZEN1_DENORM_FIX_BIT); } static bool cpu_has_zenbleed_microcode(void) -- 2.34.1

2 1

[PATCH OLK-6.6] usb: cdns3: gadget: fix state inconsistency on gadget init failure
by Xinyu Zheng 07 May '26

07 May '26

From: Yongchao Wu <yongchao.wu(a)autochips.com> stable inclusion from stable-v6.6.134 commit cfca84f5986afceb63a3adf39d4a98e915aebbc2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14504 CVE: CVE-2026-31754 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c32f8748d70c8fc77676ad92ed76cede17bf2c48 upstream. When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Yongchao Wu <yongchao.wu(a)autochips.com> Acked-by: Peter Chen <peter.chen(a)kernel.org> Link: https://patch.msgid.link/20260401001000.5761-1-yongchao.wu@autochips.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/usb/cdns3/cdns3-gadget.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c index 05e8414c31df..344de9c202cd 100644 --- a/drivers/usb/cdns3/cdns3-gadget.c +++ b/drivers/usb/cdns3/cdns3-gadget.c @@ -3428,6 +3428,7 @@ static int __cdns3_gadget_init(struct cdns *cdns) ret = cdns3_gadget_start(cdns); if (ret) { pm_runtime_put_sync(cdns->dev); + cdns_drd_gadget_off(cdns); return ret; } -- 2.34.1

2 1

[PATCH OLK-5.10] futex: Clear stale exiting pointer in futex_lock_pi() retry path
by Jiacheng Yu 07 May '26

07 May '26

From: Davidlohr Bueso <dave(a)stgolabs.net> stable inclusion from stable-v5.10.253 commit 33095ae3bdde5e5c264d7e88a2f3e7703a26c7aa category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14301 CVE: CVE-2026-31555 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 210d36d892de5195e6766c45519dfb1e65f3eb83 upstream. Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi. Fixes: 3ef240eaff36 ("futex: Prevent exit livelock") Signed-off-by: Davidlohr Bueso <dave(a)stgolabs.net> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260326001759.4129680-1-dave@stgolabs.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- kernel/futex/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/futex/core.c b/kernel/futex/core.c index cde0ca876b935..df86c0e494184 100644 --- a/kernel/futex/core.c +++ b/kernel/futex/core.c @@ -2785,9 +2785,9 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, ktime_t *time, int trylock) { struct hrtimer_sleeper timeout, *to; - struct task_struct *exiting = NULL; struct rt_mutex_waiter rt_waiter; struct futex_hash_bucket *hb; + struct task_struct *exiting; struct futex_q q = futex_q_init; int res, ret; @@ -2800,6 +2800,7 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, to = futex_setup_timer(time, &timeout, FLAGS_CLOCKRT, 0); retry: + exiting = NULL; ret = get_futex_key(uaddr, flags & FLAGS_SHARED, &q.key, FUTEX_WRITE); if (unlikely(ret != 0)) goto out; -- 2.43.0

2 1

[PATCH OLK-6.6] futex: Clear stale exiting pointer in futex_lock_pi() retry path
by Jiacheng Yu 07 May '26

07 May '26

From: Davidlohr Bueso <dave(a)stgolabs.net> stable inclusion from stable-v6.6.131 commit de7c0c04ad868f2cee6671b11c0a6d20421af1da category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14301 CVE: CVE-2026-31555 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 210d36d892de5195e6766c45519dfb1e65f3eb83 upstream. Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi. Fixes: 3ef240eaff36 ("futex: Prevent exit livelock") Signed-off-by: Davidlohr Bueso <dave(a)stgolabs.net> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260326001759.4129680-1-dave@stgolabs.net Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- kernel/futex/pi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/futex/pi.c b/kernel/futex/pi.c index ce2889f123755..9496084b6dcd8 100644 --- a/kernel/futex/pi.c +++ b/kernel/futex/pi.c @@ -930,9 +930,9 @@ int fixup_pi_owner(u32 __user *uaddr, struct futex_q *q, int locked) int futex_lock_pi(u32 __user *uaddr, unsigned int flags, ktime_t *time, int trylock) { struct hrtimer_sleeper timeout, *to; - struct task_struct *exiting = NULL; struct rt_mutex_waiter rt_waiter; struct futex_hash_bucket *hb; + struct task_struct *exiting; struct futex_q q = futex_q_init; int res, ret; @@ -945,6 +945,7 @@ int futex_lock_pi(u32 __user *uaddr, unsigned int flags, ktime_t *time, int tryl to = futex_setup_timer(time, &timeout, flags, 0); retry: + exiting = NULL; ret = get_futex_key(uaddr, flags & FLAGS_SHARED, &q.key, FUTEX_WRITE); if (unlikely(ret != 0)) goto out; -- 2.43.0

2 1

[PATCH OLK-6.6] drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib
by Jiacheng Yu 07 May '26

07 May '26

From: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com> stable inclusion from stable-v6.6.131 commit e23602eb0779760544314ed3905fa6a89a4e4070 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14312 CVE: CVE-2026-31566 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7150850146ebfa4ca998f653f264b8df6f7f85be ] amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence from amdgpu_ib_schedule(). This fence is used to wait for job completion. Currently, the code drops the fence reference using dma_fence_put() before calling dma_fence_wait(). If dma_fence_put() releases the last reference, the fence may be freed before dma_fence_wait() is called. This can lead to a use-after-free. Fix this by waiting on the fence first and releasing the reference only after dma_fence_wait() completes. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory 'f' (line 696) Fixes: 9ae55f030dc5 ("drm/amdgpu: Follow up change to previous drm scheduler change.") Cc: Felix Kuehling <Felix.Kuehling(a)amd.com> Cc: Dan Carpenter <dan.carpenter(a)linaro.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482) Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c index ce9602cb6e9c0..9d677bf10a01f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c @@ -694,9 +694,9 @@ int amdgpu_amdkfd_submit_ib(struct amdgpu_device *adev, goto err_ib_sched; } - /* Drop the initial kref_init count (see drm_sched_main as example) */ - dma_fence_put(f); ret = dma_fence_wait(f, false); + /* Drop the returned fence reference after the wait completes */ + dma_fence_put(f); err_ib_sched: amdgpu_job_free(job); -- 2.43.0

2 1

[PATCH OLK-5.10] usb: cdns3: gadget: fix state inconsistency on gadget init failure
by Xinyu Zheng 07 May '26

07 May '26

stable inclusion from stable-v6.6.134 commit cfca84f5986afceb63a3adf39d4a98e915aebbc2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14504 CVE: CVE-2026-31754 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Yongchao Wu <yongchao.wu(a)autochips.com> Acked-by: Peter Chen <peter.chen(a)kernel.org> Link: https://patch.msgid.link/20260401001000.5761-1-yongchao.wu@autochips.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/usb/cdns3/cdns3-gadget.c drivers/usb/cdns3/gadget.c [There is a refactor patch which modify 'cdns3_drd_gadget_off' to 'cdns_drd_gadget_off', this patch is not exist in current branch, so we use the old name.] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/usb/cdns3/gadget.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c index 2bd24fb806fb..1e5ccb9e021f 100644 --- a/drivers/usb/cdns3/gadget.c +++ b/drivers/usb/cdns3/gadget.c @@ -3399,6 +3399,7 @@ static int __cdns3_gadget_init(struct cdns3 *cdns) ret = cdns3_gadget_start(cdns); if (ret) { pm_runtime_put_sync(cdns->dev); + cdns3_drd_gadget_off(cdns); return ret; } -- 2.34.1

2 1

[PATCH OLK-6.6] hwmon: (pmbus/core) Protect regulator operations with mutex
by Yin Tirui 07 May '26

07 May '26

From: Guenter Roeck <linux(a)roeck-us.net> mainline inclusion from mainline-v7.0-rc6 commit 754bd2b4a084b90b5e7b630e1f423061a9b9b761 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14223 CVE: CVE-2026-31486 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- The regulator operations pmbus_regulator_get_voltage(), pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage() access PMBus registers and shared data but were not protected by the update_lock mutex. This could lead to race conditions. However, adding mutex protection directly to these functions causes a deadlock because pmbus_regulator_notify() (which calls regulator_notifier_call_chain()) is often called with the mutex already held (e.g., from pmbus_fault_handler()). If a regulator callback then calls one of the now-protected voltage functions, it will attempt to acquire the same mutex. Rework pmbus_regulator_notify() to utilize a worker function to send notifications outside of the mutex protection. Events are stored as atomics in a per-page bitmask and processed by the worker. Initialize the worker and its associated data during regulator registration, and ensure it is cancelled on device removal using devm_add_action_or_reset(). While at it, remove the unnecessary include of linux/of.h. Cc: Sanman Pradhan <psanman(a)juniper.net> Fixes: ddbb4db4ced1b ("hwmon: (pmbus) Add regulator support") Reviewed-by: Sanman Pradhan <psanman(a)juniper.net> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Yin Tirui <yintirui(a)huawei.com> --- drivers/hwmon/pmbus/pmbus_core.c | 115 ++++++++++++++++++++++++------- 1 file changed, 89 insertions(+), 26 deletions(-) diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c index 019c5982ba56..86e73303855f 100644 --- a/drivers/hwmon/pmbus/pmbus_core.c +++ b/drivers/hwmon/pmbus/pmbus_core.c @@ -6,6 +6,7 @@ * Copyright (c) 2012 Guenter Roeck */ +#include <linux/atomic.h> #include <linux/debugfs.h> #include <linux/kernel.h> #include <linux/math64.h> @@ -19,8 +20,8 @@ #include <linux/pmbus.h> #include <linux/regulator/driver.h> #include <linux/regulator/machine.h> -#include <linux/of.h> #include <linux/thermal.h> +#include <linux/workqueue.h> #include "pmbus.h" /* @@ -102,6 +103,11 @@ struct pmbus_data { struct mutex update_lock; +#if IS_ENABLED(CONFIG_REGULATOR) + atomic_t regulator_events[PMBUS_PAGES]; + struct work_struct regulator_notify_work; +#endif + bool has_status_word; /* device uses STATUS_WORD register */ int (*read_status)(struct i2c_client *client, int page); @@ -3056,12 +3062,19 @@ static int pmbus_regulator_get_voltage(struct regulator_dev *rdev) .class = PSC_VOLTAGE_OUT, .convert = true, }; + int ret; + mutex_lock(&data->update_lock); s.data = _pmbus_read_word_data(client, s.page, 0xff, PMBUS_READ_VOUT); - if (s.data < 0) - return s.data; + if (s.data < 0) { + ret = s.data; + goto unlock; + } - return (int)pmbus_reg2data(data, &s) * 1000; /* unit is uV */ + ret = (int)pmbus_reg2data(data, &s) * 1000; /* unit is uV */ +unlock: + mutex_unlock(&data->update_lock); + return ret; } static int pmbus_regulator_set_voltage(struct regulator_dev *rdev, int min_uv, @@ -3078,16 +3091,22 @@ static int pmbus_regulator_set_voltage(struct regulator_dev *rdev, int min_uv, }; int val = DIV_ROUND_CLOSEST(min_uv, 1000); /* convert to mV */ int low, high; + int ret; *selector = 0; + mutex_lock(&data->update_lock); low = pmbus_regulator_get_low_margin(client, s.page); - if (low < 0) - return low; + if (low < 0) { + ret = low; + goto unlock; + } high = pmbus_regulator_get_high_margin(client, s.page); - if (high < 0) - return high; + if (high < 0) { + ret = high; + goto unlock; + } /* Make sure we are within margins */ if (low > val) @@ -3097,7 +3116,10 @@ static int pmbus_regulator_set_voltage(struct regulator_dev *rdev, int min_uv, val = pmbus_data2reg(data, &s, val); - return _pmbus_write_word_data(client, s.page, PMBUS_VOUT_COMMAND, (u16)val); + ret = _pmbus_write_word_data(client, s.page, PMBUS_VOUT_COMMAND, (u16)val); +unlock: + mutex_unlock(&data->update_lock); + return ret; } static int pmbus_regulator_list_voltage(struct regulator_dev *rdev, @@ -3106,6 +3128,7 @@ static int pmbus_regulator_list_voltage(struct regulator_dev *rdev, struct device *dev = rdev_get_dev(rdev); struct i2c_client *client = to_i2c_client(dev->parent); int val, low, high; + int ret; if (selector >= rdev->desc->n_voltages || selector < rdev->desc->linear_min_sel) @@ -3115,18 +3138,29 @@ static int pmbus_regulator_list_voltage(struct regulator_dev *rdev, val = DIV_ROUND_CLOSEST(rdev->desc->min_uV + (rdev->desc->uV_step * selector), 1000); /* convert to mV */ + mutex_lock(&data->update_lock); + low = pmbus_regulator_get_low_margin(client, rdev_get_id(rdev)); - if (low < 0) - return low; + if (low < 0) { + ret = low; + goto unlock; + } high = pmbus_regulator_get_high_margin(client, rdev_get_id(rdev)); - if (high < 0) - return high; + if (high < 0) { + ret = high; + goto unlock; + } - if (val >= low && val <= high) - return val * 1000; /* unit is uV */ + if (val >= low && val <= high) { + ret = val * 1000; /* unit is uV */ + goto unlock; + } - return 0; + ret = 0; +unlock: + mutex_unlock(&data->update_lock); + return ret; } const struct regulator_ops pmbus_regulator_ops = { @@ -3141,12 +3175,42 @@ const struct regulator_ops pmbus_regulator_ops = { }; EXPORT_SYMBOL_NS_GPL(pmbus_regulator_ops, PMBUS); +static void pmbus_regulator_notify_work_cancel(void *data) +{ + struct pmbus_data *pdata = data; + + cancel_work_sync(&pdata->regulator_notify_work); +} + +static void pmbus_regulator_notify_worker(struct work_struct *work) +{ + struct pmbus_data *data = + container_of(work, struct pmbus_data, regulator_notify_work); + int i, j; + + for (i = 0; i < data->info->pages; i++) { + int event; + + event = atomic_xchg(&data->regulator_events[i], 0); + if (!event) + continue; + + for (j = 0; j < data->info->num_regulators; j++) { + if (i == rdev_get_id(data->rdevs[j])) { + regulator_notifier_call_chain(data->rdevs[j], + event, NULL); + break; + } + } + } +} + static int pmbus_regulator_register(struct pmbus_data *data) { struct device *dev = data->dev; const struct pmbus_driver_info *info = data->info; const struct pmbus_platform_data *pdata = dev_get_platdata(dev); - int i; + int i, ret; data->rdevs = devm_kzalloc(dev, sizeof(struct regulator_dev *) * info->num_regulators, GFP_KERNEL); @@ -3170,20 +3234,19 @@ static int pmbus_regulator_register(struct pmbus_data *data) info->reg_desc[i].name); } + INIT_WORK(&data->regulator_notify_work, pmbus_regulator_notify_worker); + + ret = devm_add_action_or_reset(dev, pmbus_regulator_notify_work_cancel, data); + if (ret) + return ret; + return 0; } static int pmbus_regulator_notify(struct pmbus_data *data, int page, int event) { - int j; - - for (j = 0; j < data->info->num_regulators; j++) { - if (page == rdev_get_id(data->rdevs[j])) { - regulator_notifier_call_chain(data->rdevs[j], event, NULL); - break; - } - } - return 0; + atomic_or(event, &data->regulator_events[page]); + schedule_work(&data->regulator_notify_work); } #else static int pmbus_regulator_register(struct pmbus_data *data) -- 2.43.0

2 1

[PATCH OLK-6.6] binfmt_elf_fdpic: fix AUXV size calculation for ELF_HWCAP3 and ELF_HWCAP4
by Pu Lehui 07 May '26

07 May '26

From: Andrei Vagin <avagin(a)google.com> mainline inclusion from mainline-v7.0-rc5 commit 4ced4cf5c9d172d91f181df3accdf949d3761aab category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9107 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit 4e6e8c2b757f ("binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4") added support for AT_HWCAP3 and AT_HWCAP4, but it missed updating the AUX vector size calculation in create_elf_fdpic_tables() and AT_VECTOR_SIZE_BASE in include/linux/auxvec.h. Similar to the fix for AT_HWCAP2 in commit c6a09e342f8e ("binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined"), this omission leads to a mismatch between the reserved space and the actual number of AUX entries, eventually triggering a kernel BUG_ON(csp != sp). Fix this by incrementing nitems when ELF_HWCAP3 or ELF_HWCAP4 are defined and updating AT_VECTOR_SIZE_BASE. Cc: Mark Brown <broonie(a)kernel.org> Cc: Max Filippov <jcmvbkbc(a)gmail.com> Reviewed-by: Michal Koutný <mkoutny(a)suse.com> Reviewed-by: Mark Brown <broonie(a)kernel.org> Reviewed-by: Cyrill Gorcunov <gorcunov(a)gmail.com> Reviewed-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn(a)futurfusion.io> Fixes: 4e6e8c2b757f ("binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4") Signed-off-by: Andrei Vagin <avagin(a)google.com> Link: https://patch.msgid.link/20260217180108.1420024-2-avagin@google.com Signed-off-by: Kees Cook <kees(a)kernel.org> Conflicts: fs/binfmt_elf_fdpic.c [ctx conflicts] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- fs/binfmt_elf_fdpic.c | 6 ++++++ include/linux/auxvec.h | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index 7419c3a41db9..0f51f205efb6 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -591,6 +591,12 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, if (bprm->have_execfd) nitems++; +#ifdef ELF_HWCAP3 + nitems++; +#endif +#ifdef ELF_HWCAP4 + nitems++; +#endif csp = sp; sp -= nitems * 2 * sizeof(unsigned long); diff --git a/include/linux/auxvec.h b/include/linux/auxvec.h index 407f7005e6d6..8bcb9b726262 100644 --- a/include/linux/auxvec.h +++ b/include/linux/auxvec.h @@ -4,6 +4,6 @@ #include <uapi/linux/auxvec.h> -#define AT_VECTOR_SIZE_BASE 22 /* NEW_AUX_ENT entries in auxiliary table */ +#define AT_VECTOR_SIZE_BASE 24 /* NEW_AUX_ENT entries in auxiliary table */ /* number of "#define AT_.*" above, minus {AT_NULL, AT_IGNORE, AT_NOTELF} */ #endif /* _LINUX_AUXVEC_H */ -- 2.34.1

2 1

[PATCH OLK-5.10] perf/x86/intel/uncore: Skip discovery table for offline dies
by Luo Gengkun 07 May '26

07 May '26

From: Zide Chen <zide.chen(a)intel.com> stable inclusion from stable-v6.6.136 commit cfab2c817d2e7e0bee98d66850246ce842ed5f18 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14628 CVE: CVE-2026-43079 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 7b568e9eba2fad89a696f22f0413d44cf4a1f892 ] This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues. Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables") Reported-by: Steve Wahl <steve.wahl(a)hpe.com> Signed-off-by: Zide Chen <zide.chen(a)intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> Tested-by: Steve Wahl <steve.wahl(a)hpe.com> Link: https://patch.msgid.link/20260313174050.171704-3-zide.chen@intel.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- arch/x86/events/intel/uncore_discovery.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/intel/uncore_discovery.c b/arch/x86/events/intel/uncore_discovery.c index a543a54fd714..6765f31479c5 100644 --- a/arch/x86/events/intel/uncore_discovery.c +++ b/arch/x86/events/intel/uncore_discovery.c @@ -382,7 +382,7 @@ static bool intel_uncore_has_discovery_tables_pci(int *ignore) (val & UNCORE_DISCOVERY_DVSEC2_BIR_MASK) * UNCORE_DISCOVERY_BIR_STEP; die = get_device_die_id(dev); - if (die < 0) + if ((die < 0) || (die >= uncore_max_dies())) continue; parse_discovery_table(dev, die, bar_offset, &parsed, ignore); -- 2.34.1

2 1

[PATCH OLK-5.10] pstore: ram_core: fix incorrect success return when vmap() fails
by Luo Gengkun 07 May '26

07 May '26

From: Ruipeng Qi <ruipengqi3(a)gmail.com> stable inclusion from stable-v5.10.252 commit d47234840aeb4182ed3ee795c578b1dfa9cbd25b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14671 CVE: CVE-2026-43124 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi <ruipengqi3(a)gmail.com> Link: https://patch.msgid.link/20260203020358.3315299-1-ruipengqi3@gmail.com Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- fs/pstore/ram_core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index 5ac9b1f155a8..90483b0ba5b9 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -432,6 +432,13 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size, vaddr = vmap(pages, page_count, VM_MAP | VM_IOREMAP, prot); kfree(pages); + /* + * vmap() may fail and return NULL. Do not add the offset in this + * case, otherwise a NULL mapping would appear successful. + */ + if (!vaddr) + return NULL; + /* * Since vmap() uses page granularity, we must add the offset * into the page here, to get the byte granularity address -- 2.34.1

2 1

[PATCH OLK-6.6 0/8] cgroupv2 io bugfix patches
by Zizhi Wo 07 May '26

07 May '26

cgroupv2 io bugfix patches David Laight (1): block: use min() instead of min_t() Jialin Wang (1): blk-iocost: fix busy_level reset when no IOs complete Julian Sun (1): jbd2: increase IO priority of checkpoint Li Lingfeng (1): block: flush all throttled bios when deleting the cgroup Ming Lei (1): blk-throttle: don't take carryover for prioritized processing of metadata Yu Kuai (3): blk-throttle: fix lower control under super low iops limit blk-throttle: support prioritized processing of metadata blk-throttle: fix lower bps rate by throtl_trim_slice() block/blk-iocost.c | 29 ++++++--- block/blk-throttle.c | 140 +++++++++++++++++++++++++++-------------- block/partitions/efi.c | 3 +- fs/jbd2/checkpoint.c | 2 +- 4 files changed, 113 insertions(+), 61 deletions(-) -- 2.52.0

2 9

[PATCH OLK-6.6] perf/x86/intel/uncore: Skip discovery table for offline dies
by Luo Gengkun 07 May '26

07 May '26

From: Zide Chen <zide.chen(a)intel.com> stable inclusion from stable-v6.6.136 commit cfab2c817d2e7e0bee98d66850246ce842ed5f18 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14628 CVE: CVE-2026-43079 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 7b568e9eba2fad89a696f22f0413d44cf4a1f892 ] This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues. Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables") Reported-by: Steve Wahl <steve.wahl(a)hpe.com> Signed-off-by: Zide Chen <zide.chen(a)intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> Tested-by: Steve Wahl <steve.wahl(a)hpe.com> Link: https://patch.msgid.link/20260313174050.171704-3-zide.chen@intel.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- arch/x86/events/intel/uncore_discovery.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/intel/uncore_discovery.c b/arch/x86/events/intel/uncore_discovery.c index a543a54fd714..6765f31479c5 100644 --- a/arch/x86/events/intel/uncore_discovery.c +++ b/arch/x86/events/intel/uncore_discovery.c @@ -382,7 +382,7 @@ static bool intel_uncore_has_discovery_tables_pci(int *ignore) (val & UNCORE_DISCOVERY_DVSEC2_BIR_MASK) * UNCORE_DISCOVERY_BIR_STEP; die = get_device_die_id(dev); - if (die < 0) + if ((die < 0) || (die >= uncore_max_dies())) continue; parse_discovery_table(dev, die, bar_offset, &parsed, ignore); -- 2.34.1

2 1

[PATCH OLK-6.6] pstore: ram_core: fix incorrect success return when vmap() fails
by Luo Gengkun 07 May '26

07 May '26

From: Ruipeng Qi <ruipengqi3(a)gmail.com> stable inclusion from stable-v6.6.128 commit 1da904e84de608907662ad8a51ba9c571d61e003 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14671 CVE: CVE-2026-43124 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi <ruipengqi3(a)gmail.com> Link: https://patch.msgid.link/20260203020358.3315299-1-ruipengqi3@gmail.com Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- fs/pstore/ram_core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index c9eaacdec37e..7b6d6378a3b8 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -457,6 +457,13 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size, vaddr = vmap(pages, page_count, VM_MAP | VM_IOREMAP, prot); kfree(pages); + /* + * vmap() may fail and return NULL. Do not add the offset in this + * case, otherwise a NULL mapping would appear successful. + */ + if (!vaddr) + return NULL; + /* * Since vmap() uses page granularity, we must add the offset * into the page here, to get the byte granularity address -- 2.34.1

2 1

[PATCH OLK-6.6] mm: memcontrol: don't throttle dying tasks on memory.high
by Jinjiang Tu 07 May '26

07 May '26

From: Johannes Weiner <hannes(a)cmpxchg.org> mainline inclusion from mainline-v6.8-rc3 commit 63fd327016fdfca6f2fa27eba3496bd079eb8ed3 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9095 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- While investigating hosts with high cgroup memory pressures, Tejun found culprit zombie tasks that had were holding on to a lot of memory, had SIGKILL pending, but were stuck in memory.high reclaim. In the past, we used to always force-charge allocations from tasks that were exiting in order to accelerate them dying and freeing up their rss. This changed for memory.max in a4ebf1b6ca1e ("memcg: prohibit unconditional exceeding the limit of dying tasks"); it noted that this can cause (userspace inducable) containment failures, so it added a mandatory reclaim and OOM kill cycle before forcing charges. At the time, memory.high enforcement was handled in the userspace return path, which isn't reached by dying tasks, and so memory.high was still never enforced by dying tasks. When c9afe31ec443 ("memcg: synchronously enforce memory.high for large overcharges") added synchronous reclaim for memory.high, it added unconditional memory.high enforcement for dying tasks as well. The callstack shows that this path is where the zombie is stuck in. We need to accelerate dying tasks getting past memory.high, but we cannot do it quite the same way as we do for memory.max: memory.max is enforced strictly, and tasks aren't allowed to move past it without FIRST reclaiming and OOM killing if necessary. This ensures very small levels of excess. With memory.high, though, enforcement happens lazily after the charge, and OOM killing is never triggered. A lot of concurrent threads could have pushed, or could actively be pushing, the cgroup into excess. The dying task will enter reclaim on every allocation attempt, with little hope of restoring balance. To fix this, skip synchronous memory.high enforcement on dying tasks altogether again. Update memory.high path documentation while at it. [hannes(a)cmpxchg.org: also handle tasks are being killed during the reclaim] Link: https://lkml.kernel.org/r/20240111192807.GA424308@cmpxchg.org Link: https://lkml.kernel.org/r/20240111132902.389862-1-hannes@cmpxchg.org Fixes: c9afe31ec443 ("memcg: synchronously enforce memory.high for large overcharges") Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Reported-by: Tejun Heo <tj(a)kernel.org> Reviewed-by: Yosry Ahmed <yosryahmed(a)google.com> Acked-by: Shakeel Butt <shakeelb(a)google.com> Acked-by: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Dan Schatzberg <schatzberg.dan(a)gmail.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Muchun Song <muchun.song(a)linux.dev> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/memcontrol.c [hulk feature: 'fine grained stall' causes conflicts] Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/memcontrol.c | 29 +++++++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index ac2b4b1060fd..46411dead693 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2769,8 +2769,9 @@ static unsigned long calculate_high_delay(struct mem_cgroup *memcg, } /* - * Scheduled by try_charge() to be executed from the userland return path - * and reclaims memory over the high limit. + * Reclaims memory over the high limit. Called directly from + * try_charge() (context permitting), as well as from the userland + * return path where reclaim is always able to block. */ void mem_cgroup_handle_over_high(gfp_t gfp_mask) { @@ -2789,6 +2790,17 @@ void mem_cgroup_handle_over_high(gfp_t gfp_mask) current->memcg_nr_pages_over_high = 0; retry_reclaim: + /* + * Bail if the task is already exiting. Unlike memory.max, + * memory.high enforcement isn't as strict, and there is no + * OOM killer involved, which means the excess could already + * be much bigger (and still growing) than it could for + * memory.max; the dying task could get stuck in fruitless + * reclaim for a long time, which isn't desirable. + */ + if (task_is_dying()) + goto out; + /* * The allocating task should reclaim at least the batch size, but for * subsequent retries we only want to do what's necessary to prevent oom @@ -2839,6 +2851,9 @@ void mem_cgroup_handle_over_high(gfp_t gfp_mask) } /* + * Reclaim didn't manage to push usage below the limit, slow + * this allocating task down. + * * If we exit early, we're guaranteed to die (since * schedule_timeout_killable sets TASK_KILLABLE). This means we don't * need to account for any ill-begotten jiffies to pay them off later. @@ -3049,11 +3064,17 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, } } while ((memcg = parent_mem_cgroup(memcg))); + /* + * Reclaim is set up above to be called from the userland + * return path. But also attempt synchronous reclaim to avoid + * excessive overrun while the task is still inside the + * kernel. If this is successful, the return path will see it + * when it rechecks the overage and simply bail out. + */ if (current->memcg_nr_pages_over_high > MEMCG_CHARGE_BATCH && !(current->flags & PF_MEMALLOC) && - gfpflags_allow_blocking(gfp_mask)) { + gfpflags_allow_blocking(gfp_mask)) mem_cgroup_handle_over_high(gfp_mask); - } return 0; } -- 2.43.0

2 1

[PATCH OLK-6.6] dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()
by Zhang Yuwei 07 May '26

07 May '26

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v7.0-rc6 commit e1c9866173c5f8521f2d0768547a01508cb9ff27 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14179 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Conflicts: drivers/dma/idxd/submit.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/dma/idxd/submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/idxd/submit.c b/drivers/dma/idxd/submit.c index 817a564413b0..111e9dd8ebda 100644 --- a/drivers/dma/idxd/submit.c +++ b/drivers/dma/idxd/submit.c @@ -138,7 +138,7 @@ static void llist_abort_desc(struct idxd_wq *wq, struct idxd_irq_entry *ie, */ list_for_each_entry_safe(d, t, &flist, list) { list_del_init(&d->list); - idxd_dma_complete_txd(found, IDXD_COMPLETE_ABORT, true, + idxd_dma_complete_txd(d, IDXD_COMPLETE_ABORT, true, NULL, NULL); } } -- 2.22.0

2 1

[PATCH OLK-6.6] dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()
by Zhang Yuwei 07 May '26

07 May '26

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v7.0-rc6 commit e1c9866173c5f8521f2d0768547a01508cb9ff27 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14179 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Conflicts: drivers/dma/idxd/submit.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/dma/idxd/submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/idxd/submit.c b/drivers/dma/idxd/submit.c index 817a564413b0..111e9dd8ebda 100644 --- a/drivers/dma/idxd/submit.c +++ b/drivers/dma/idxd/submit.c @@ -138,7 +138,7 @@ static void llist_abort_desc(struct idxd_wq *wq, struct idxd_irq_entry *ie, */ list_for_each_entry_safe(d, t, &flist, list) { list_del_init(&d->list); - idxd_dma_complete_txd(found, IDXD_COMPLETE_ABORT, true, + idxd_dma_complete_txd(d, IDXD_COMPLETE_ABORT, true, NULL, NULL); } } -- 2.22.0

2 1

[PATCH OLK-6.6 v9 0/2] kvm: arm64: Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 07 May '26

07 May '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register. liqiqi (2): kvm: arm64: Add MIDR definitions and use MIDR to determine whether features are supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 6 ++ arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 115 ++++----------------------- arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 21 insertions(+), 113 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6] dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()
by Zhang Yuwei 07 May '26

07 May '26

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v7.0-rc6 commit e1c9866173c5f8521f2d0768547a01508cb9ff27 category: https://atomgit.com/src-openeuler/kernel/issues/14179 bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Conflicts: drivers/dma/idxd/submit.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/dma/idxd/submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/idxd/submit.c b/drivers/dma/idxd/submit.c index 817a564413b0..111e9dd8ebda 100644 --- a/drivers/dma/idxd/submit.c +++ b/drivers/dma/idxd/submit.c @@ -138,7 +138,7 @@ static void llist_abort_desc(struct idxd_wq *wq, struct idxd_irq_entry *ie, */ list_for_each_entry_safe(d, t, &flist, list) { list_del_init(&d->list); - idxd_dma_complete_txd(found, IDXD_COMPLETE_ABORT, true, + idxd_dma_complete_txd(d, IDXD_COMPLETE_ABORT, true, NULL, NULL); } } -- 2.22.0

2 1

[PATCH OLK-6.6] dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()
by Zhang Yuwei 07 May '26

07 May '26

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v7.0-rc6 commit e1c9866173c5f8521f2d0768547a01508cb9ff27 category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Conflicts: drivers/dma/idxd/submit.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/dma/idxd/submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/idxd/submit.c b/drivers/dma/idxd/submit.c index 817a564413b0..111e9dd8ebda 100644 --- a/drivers/dma/idxd/submit.c +++ b/drivers/dma/idxd/submit.c @@ -138,7 +138,7 @@ static void llist_abort_desc(struct idxd_wq *wq, struct idxd_irq_entry *ie, */ list_for_each_entry_safe(d, t, &flist, list) { list_del_init(&d->list); - idxd_dma_complete_txd(found, IDXD_COMPLETE_ABORT, true, + idxd_dma_complete_txd(d, IDXD_COMPLETE_ABORT, true, NULL, NULL); } } -- 2.22.0

2 1

[PATCH OLK-6.6 0/2] support mempool and NUMA.remote for 64KB page
by Jinjiang Tu 07 May '26

07 May '26

support mempool and NUMA.remote for 64KB page. Jinjiang Tu (2): mm/pfn_range_alloc: add support for CONFIG_ARM64_64K_PAGES mm/numa_remote: remove depends on ARM64_4K_PAGES arch/arm64/mm/Kconfig | 1 + arch/arm64/mm/pfn_range_alloc.c | 31 ++++++++++++++++++++++++------- drivers/base/Kconfig | 2 +- 3 files changed, 26 insertions(+), 8 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6] PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup
by Hongtao Zhang 06 May '26

06 May '26

From: Koichiro Den <den(a)valinux.co.jp> stable inclusion from stable-v6.12.83 commit 6773cc24c004930903a57761132c1e7728907f8f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14339 CVE: CVE-2026-31595 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit d799984233a50abd2667a7d17a9a710a3f10ebe2 upstream. Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down. Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20 Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den <den(a)valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani(a)kernel.org> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260226084142.2226875-4-den@valinux.co.jp Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Hongtao <zhanghongtao35(a)huawei.com> --- drivers/pci/endpoint/functions/pci-epf-vntb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c index 33c3f9b980e68..990c27a2cd8d7 100644 --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c @@ -810,6 +810,7 @@ static int epf_ntb_epc_init(struct epf_ntb *ntb) */ static void epf_ntb_epc_cleanup(struct epf_ntb *ntb) { + disable_delayed_work_sync(&ntb->cmd_handler); epf_ntb_mw_bar_clear(ntb, ntb->num_mws); epf_ntb_db_bar_clear(ntb); epf_ntb_config_sspad_bar_clear(ntb); -- 2.43.0

2 1

[PATCH OLK-6.6] xen/privcmd: fix double free via VMA splitting
by Lin Ruifeng 06 May '26

06 May '26

From: Juergen Gross <jgross(a)suse.com> stable inclusion from stable-v6.6.137 commit 402d84ad9e89bd4cbfd07ca8598532b7021daf95 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14442 CVE: CVE-2026-31787 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 24daca4fc07f3ff8cd0e3f629cd982187f48436a upstream. privcmd_vm_ops defines .close (privcmd_close), but neither .may_split nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via __split_vma(). Since may_split is NULL, the split is allowed. vm_area_dup() copies vm_private_data (a pages array allocated in alloc_empty_pages()) into the new VMA without any fixup, because there is no .open callback. Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages) The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free. Fix this issue by adding a .may_split callback denying the VMA split. This is XSA-487 / CVE-2026-31787 Fixes: d71f513985c2 ("xen: privcmd: support autotranslated physmap guests.") Reported-by: Atharva Vartak <atharva.a.vartak(a)gmail.com> Suggested-by: Atharva Vartak <atharva.a.vartak(a)gmail.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Jan Beulich <jbeulich(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/xen/privcmd.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 74d6a2bd6d04..5049182ec9e9 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -1211,6 +1211,12 @@ static void privcmd_close(struct vm_area_struct *vma) kvfree(pages); } +static int privcmd_may_split(struct vm_area_struct *area, unsigned long addr) +{ + /* Forbid splitting, avoids double free via privcmd_close(). */ + return -EINVAL; +} + static vm_fault_t privcmd_fault(struct vm_fault *vmf) { printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n", @@ -1222,6 +1228,7 @@ static vm_fault_t privcmd_fault(struct vm_fault *vmf) static const struct vm_operations_struct privcmd_vm_ops = { .close = privcmd_close, + .may_split = privcmd_may_split, .fault = privcmd_fault }; -- 2.43.0

2 1

[PATCH OLK-5.10] xen/privcmd: fix double free via VMA splitting
by Lin Ruifeng 06 May '26

06 May '26

From: Juergen Gross <jgross(a)suse.com> stable inclusion from stable-v5.10.254 commit dbf862ce9f009128ab86b234d91413a3e450beb4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14442 CVE: CVE-2026-31787 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 24daca4fc07f3ff8cd0e3f629cd982187f48436a upstream. privcmd_vm_ops defines .close (privcmd_close), but neither .may_split nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via __split_vma(). Since may_split is NULL, the split is allowed. vm_area_dup() copies vm_private_data (a pages array allocated in alloc_empty_pages()) into the new VMA without any fixup, because there is no .open callback. Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages) The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free. Fix this issue by adding a .may_split callback denying the VMA split. This is XSA-487 / CVE-2026-31787 Fixes: d71f513985c2 ("xen: privcmd: support autotranslated physmap guests.") Reported-by: Atharva Vartak <atharva.a.vartak(a)gmail.com> Suggested-by: Atharva Vartak <atharva.a.vartak(a)gmail.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Jan Beulich <jbeulich(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/xen/privcmd.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 3f198ded58b8..2aa40e58cb94 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -933,6 +933,12 @@ static void privcmd_close(struct vm_area_struct *vma) kfree(pages); } +static int privcmd_may_split(struct vm_area_struct *area, unsigned long addr) +{ + /* Forbid splitting, avoids double free via privcmd_close(). */ + return -EINVAL; +} + static vm_fault_t privcmd_fault(struct vm_fault *vmf) { printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n", @@ -944,6 +950,7 @@ static vm_fault_t privcmd_fault(struct vm_fault *vmf) static const struct vm_operations_struct privcmd_vm_ops = { .close = privcmd_close, + .split = privcmd_may_split, .fault = privcmd_fault }; -- 2.43.0

2 1

[PATCH OLK-5.10] Buffer overflow in drivers/xen/sys-hypervisor.c
by Lin Ruifeng 06 May '26

06 May '26

From: Juergen Gross <jgross(a)suse.com> mainline inclusion from mainline-v7.1-rc2 commit 27fdbab4221b375de54bf91919798d88520c6e28 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14442 CVE: CVE-2026-31786 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The build id returned by HYPERVISOR_xen_version(XENVER_build_id) is neither NUL terminated nor a string. The first causes a buffer overflow as sprintf in buildid_show will read and copy till it finds a NUL. 00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P| 00000010 b9 a8 01 42 6f 2e 32 |...Bo.2| 00000017 So use a memcpy instead of sprintf to have the correct value: 00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P| 00000010 b9 a8 01 42 |...B| 00000014 (the above have a hack to embed a zero inside and check it's returned correctly). This is XSA-485 / CVE-2026-31786 Fixes: 84b7625728ea ("xen: add sysfs node for hypervisor build id") Signed-off-by: Frediano Ziglio <frediano.ziglio(a)citrix.com> Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/xen/sys-hypervisor.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c index feb1d16252e7..989c9a6e1d18 100644 --- a/drivers/xen/sys-hypervisor.c +++ b/drivers/xen/sys-hypervisor.c @@ -364,6 +364,8 @@ static ssize_t buildid_show(struct hyp_sysfs_attr *attr, char *buffer) ret = sprintf(buffer, "<denied>"); return ret; } + if (ret > PAGE_SIZE) + return -ENOSPC; buildid = kmalloc(sizeof(*buildid) + ret, GFP_KERNEL); if (!buildid) @@ -371,8 +373,10 @@ static ssize_t buildid_show(struct hyp_sysfs_attr *attr, char *buffer) buildid->len = ret; ret = HYPERVISOR_xen_version(XENVER_build_id, buildid); - if (ret > 0) - ret = sprintf(buffer, "%s", buildid->buf); + if (ret > 0) { + /* Build id is binary, not a string. */ + memcpy(buffer, buildid->buf, ret); + } kfree(buildid); return ret; -- 2.43.0

2 1

[PATCH OLK-6.6 0/2] *** fix CVE-2026-31443 ***
by Lin Ruifeng 06 May '26

06 May '26

*** fix CVE-2026-31443 *** Dan Carpenter (1): dmaengine: idxd: Delete unnecessary NULL check Vinicius Costa Gomes (1): dmaengine: idxd: Fix crash when the event log is disabled drivers/dma/idxd/device.c | 3 +++ drivers/dma/idxd/init.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) -- 2.43.0

2 3

[PATCH OLK-6.6] spi: spi-dw-dma: fix print error log when wait finish transaction
by Lin Ruifeng 06 May '26

06 May '26

From: Vladimir Yakovlev <vovchkir(a)gmail.com> stable inclusion from stable-v6.19.11 commit 184f5aaf72f1f1c73e66bae0b8d28e81c2f2a72f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14306 CVE: CVE-2026-31560 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3b46d61890632c8f8b117147b6923bff4b42ccb7 ] If an error occurs, the device may not have a current message. In this case, the system will crash. In this case, it's better to use dev from the struct ctlr (struct spi_controller*). Signed-off-by: Vladimir Yakovlev <vovchkir(a)gmail.com> Link: https://patch.msgid.link/20260302222017.992228-2-vovchkir@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/spi/spi-dw-dma.c [Context conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/spi/spi-dw-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-dw-dma.c b/drivers/spi/spi-dw-dma.c index 0ecbb6c36e23..a3bedcdf6f71 100644 --- a/drivers/spi/spi-dw-dma.c +++ b/drivers/spi/spi-dw-dma.c @@ -271,7 +271,7 @@ static int dw_spi_dma_wait(struct dw_spi *dws, unsigned int len, u32 speed) msecs_to_jiffies(ms)); if (ms == 0) { - dev_err(&dws->host->cur_msg->spi->dev, + dev_err(&dws->host->dev, "DMA transaction timed out\n"); return -ETIMEDOUT; } -- 2.43.0

2 1

[PATCH OLK-5.10] spi: spi-dw-dma: fix print error log when wait finish transaction
by Lin Ruifeng 06 May '26

06 May '26

From: Vladimir Yakovlev <vovchkir(a)gmail.com> stable inclusion from stable-v6.19.11 commit 184f5aaf72f1f1c73e66bae0b8d28e81c2f2a72f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14306 CVE: CVE-2026-31560 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3b46d61890632c8f8b117147b6923bff4b42ccb7 ] If an error occurs, the device may not have a current message. In this case, the system will crash. In this case, it's better to use dev from the struct ctlr (struct spi_controller*). Signed-off-by: Vladimir Yakovlev <vovchkir(a)gmail.com> Link: https://patch.msgid.link/20260302222017.992228-2-vovchkir@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/spi/spi-dw-dma.c [Context conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/spi/spi-dw-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-dw-dma.c b/drivers/spi/spi-dw-dma.c index 32ac8f9068e8..35e36f75afbb 100644 --- a/drivers/spi/spi-dw-dma.c +++ b/drivers/spi/spi-dw-dma.c @@ -219,7 +219,7 @@ static int dw_spi_dma_wait(struct dw_spi *dws, unsigned int len, u32 speed) msecs_to_jiffies(ms)); if (ms == 0) { - dev_err(&dws->master->cur_msg->spi->dev, + dev_err(&dws->master->dev, "DMA transaction timed out\n"); return -ETIMEDOUT; } -- 2.43.0

2 1

[PATCH OLK-6.6] perf/x86: Fix potential bad container_of in intel_pmu_hw_config
by Luo Gengkun 06 May '26

06 May '26

From: Ian Rogers <irogers(a)google.com> mainline inclusion from mainline-v7.0-rc7 commit dbde07f06226438cd2cf1179745fa1bec5d8914a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14532 CVE: CVE-2026-31782 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86_hybrid_pmu and a container_of operation in intel_pmu_set_acr_caused_constr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intel_pmu_set_acr_caused_constr with an is_x86_event check. Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload") Signed-off-by: Ian Rogers <irogers(a)google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon(a)intel.com> Link: https://patch.msgid.link/20260312194305.1834035-1-irogers@google.com Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- arch/x86/events/intel/core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 1844d4917bbb..dcaa72ba5dfd 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4423,8 +4423,10 @@ static int intel_pmu_hw_config(struct perf_event *event) intel_pmu_set_acr_caused_constr(leader, idx++, cause_mask); if (leader->nr_siblings) { - for_each_sibling_event(sibling, leader) - intel_pmu_set_acr_caused_constr(sibling, idx++, cause_mask); + for_each_sibling_event(sibling, leader) { + if (is_x86_event(sibling)) + intel_pmu_set_acr_caused_constr(sibling, idx++, cause_mask); + } } if (leader != event) -- 2.34.1

2 1

[PATCH OLK-6.6] drm/i915/gt: Check set_default_submission() before deferencing
by Hongtao Zhang 06 May '26

06 May '26

From: Rahul Bukte <rahul.bukte(a)sony.com> stable inclusion from stable-v6.6.130 commit df1f4a7d9cf689b4e96c95255228896505f44c31 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14286 CVE: CVE-2026-31540 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0162ab3220bac870e43e229e6e3024d1a21c3f26 ] When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] <TASK> [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] </TASK> [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------ Signed-off-by: Rahul Bukte <rahul.bukte(a)sony.com> Reviewed-by: Suraj Kandpal <suraj.kandpal(a)intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal(a)intel.com> Link: https://patch.msgid.link/20260203044839.1555147-1-suraj.kandpal@intel.com (cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad) Fixes: ff44ad51ebf8 ("drm/i915: Move engine->submit_request selection to a vfunc") Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Hongtao <zhanghongtao35(a)huawei.com> --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 0729ab5955171..6ea2c14f78160 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -1973,7 +1973,8 @@ void intel_engines_reset_default_submission(struct intel_gt *gt) if (engine->sanitize) engine->sanitize(engine); - engine->set_default_submission(engine); + if (engine->set_default_submission) + engine->set_default_submission(engine); } } -- 2.43.0

2 1

[PATCH OLK-6.6 0/5] CVE
by Liu Kai 06 May '26

06 May '26

CVE Helen Koike (1): Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Hyunwoo Kim (3): Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del() Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() Luiz Augusto von Dentz (1): Bluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete net/bluetooth/l2cap_core.c | 32 ++++++++++++++++++++------------ net/bluetooth/l2cap_sock.c | 3 +++ net/bluetooth/mgmt.c | 2 +- 3 files changed, 24 insertions(+), 13 deletions(-) -- 2.34.1

2 6

[PATCH OLK-6.6] iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()
by Pan Taixi 06 May '26

06 May '26

From: Kohei Enju <kohei(a)enjuk.jp> mainline inclusion from mainline-v7.0-rc6 commit fecacfc95f195b99c71c579a472120d0b4ed65fa category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14241 CVE: CVE-2026-31505 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the value could change in runtime, we should use num_tx_queues instead. Moreover iavf_get_ethtool_stats() uses num_active_queues while iavf_get_sset_count() and iavf_get_stat_strings() use real_num_tx_queues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1]. For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3: Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavf_set_channels() ... iavf_alloc_queues() -> num_active_queues = 8 iavf_schedule_finish_config() iavf_get_sset_count() real_num_tx_queues: 1 -> buffer for 1 queue iavf_get_ethtool_stats() num_active_queues: 8 -> out-of-bounds! iavf_finish_config() -> real_num_tx_queues = 8 Use immutable num_tx_queues in all related functions to avoid the issue. [1] BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800 CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK> The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fixes: 64430f70ba6f ("iavf: Fix displaying queue statistics shown by ethtool") Signed-off-by: Kohei Enju <kohei(a)enjuk.jp> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel(a)intel.com> Reviewed-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Tested-by: Rafal Romanowski <rafal.romanowski(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Conflicts: drivers/net/ethernet/intel/iavf/iavf_ethtool.c [Context conflicts due to ummerged commit 53844673d555 ("iavf: kill "legacy-rx" for good")] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- .../net/ethernet/intel/iavf/iavf_ethtool.c | 31 +++++++++---------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c index 1ac97bd606e3..f2288e2aedb0 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c +++ b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c @@ -334,14 +334,13 @@ static int iavf_get_sset_count(struct net_device *netdev, int sset) { /* Report the maximum number queues, even if not every queue is * currently configured. Since allocation of queues is in pairs, - * use netdev->real_num_tx_queues * 2. The real_num_tx_queues is set - * at device creation and never changes. + * use netdev->num_tx_queues * 2. The num_tx_queues is set at + * device creation and never changes. */ if (sset == ETH_SS_STATS) return IAVF_STATS_LEN + - (IAVF_QUEUE_STATS_LEN * 2 * - netdev->real_num_tx_queues); + (IAVF_QUEUE_STATS_LEN * 2 * netdev->num_tx_queues); else if (sset == ETH_SS_PRIV_FLAGS) return IAVF_PRIV_FLAGS_STR_LEN; else @@ -368,19 +367,19 @@ static void iavf_get_ethtool_stats(struct net_device *netdev, iavf_add_ethtool_stats(&data, adapter, iavf_gstrings_stats); rcu_read_lock(); - /* As num_active_queues describe both tx and rx queues, we can use - * it to iterate over rings' stats. + /* Use num_tx_queues to report stats for the maximum number of queues. + * Queues beyond num_active_queues will report zero. */ - for (i = 0; i < adapter->num_active_queues; i++) { - struct iavf_ring *ring; + for (i = 0; i < netdev->num_tx_queues; i++) { + struct iavf_ring *tx_ring = NULL, *rx_ring = NULL; - /* Tx rings stats */ - ring = &adapter->tx_rings[i]; - iavf_add_queue_stats(&data, ring); + if (i < adapter->num_active_queues) { + tx_ring = &adapter->tx_rings[i]; + rx_ring = &adapter->rx_rings[i]; + } - /* Rx rings stats */ - ring = &adapter->rx_rings[i]; - iavf_add_queue_stats(&data, ring); + iavf_add_queue_stats(&data, tx_ring); + iavf_add_queue_stats(&data, rx_ring); } rcu_read_unlock(); } @@ -417,9 +416,9 @@ static void iavf_get_stat_strings(struct net_device *netdev, u8 *data) iavf_add_stat_strings(&data, iavf_gstrings_stats); /* Queues are always allocated in pairs, so we just use - * real_num_tx_queues for both Tx and Rx queues. + * num_tx_queues for both Tx and Rx queues. */ - for (i = 0; i < netdev->real_num_tx_queues; i++) { + for (i = 0; i < netdev->num_tx_queues; i++) { iavf_add_stat_strings(&data, iavf_gstrings_queue_stats, "tx", i); iavf_add_stat_strings(&data, iavf_gstrings_queue_stats, -- 2.34.1

2 1

[PATCH OLK-6.6 0/9] Fix CVE-2026-31431
by Lu Jialin 01 May '26

01 May '26

Douya Le (1): crypto: algif_aead - snapshot IV for async AEAD requests Eric Biggers (3): crypto: scatterwalk - Backport memcpy_sglist() crypto: algif_aead - use memcpy_sglist() instead of null skcipher crypto: authenc - use memcpy_sglist() instead of null skcipher Herbert Xu (5): crypto: algif_aead - Fix minimum RX size check for decryption crypto: algif_aead - Revert to operating out-of-place crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption crypto: authencesn - Fix src offset when decrypting in-place crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl crypto/Kconfig | 2 - crypto/af_alg.c | 51 ++------- crypto/algif_aead.c | 205 +++++++---------------------------- crypto/algif_skcipher.c | 6 +- crypto/authenc.c | 32 +----- crypto/authencesn.c | 84 ++++++-------- crypto/scatterwalk.c | 94 ++++++++++++++++ include/crypto/if_alg.h | 5 +- include/crypto/scatterwalk.h | 31 ++++++ 9 files changed, 216 insertions(+), 294 deletions(-) -- 2.34.1

2 10

[PATCH openEuler-1.0-LTS v4 00/10] CVE-2026-31431
by GONG Ruiqi 30 Apr '26

30 Apr '26

Douya Le (1): crypto: algif_aead - snapshot IV for async AEAD requests Eric Biggers (3): crypto: scatterwalk - Backport memcpy_sglist() crypto: algif_aead - use memcpy_sglist() instead of null skcipher crypto: authenc - use memcpy_sglist() instead of null skcipher Herbert Xu (5): crypto: algif_aead - Revert to operating out-of-place crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption crypto: authencesn - Fix src offset when decrypting in-place crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl crypto: algif_aead - Fix minimum RX size check for decryption Randy Dunlap (1): crypto: doc - fix kernel-doc notation in chacha.c and af_alg.c crypto/Kconfig | 2 - crypto/af_alg.c | 138 +++++++++++------------- crypto/algif_aead.c | 203 ++++++++--------------------------- crypto/algif_skcipher.c | 6 +- crypto/authenc.c | 32 +----- crypto/authencesn.c | 84 ++++++--------- crypto/scatterwalk.c | 98 +++++++++++++++++ include/crypto/if_alg.h | 5 +- include/crypto/scatterwalk.h | 32 ++++++ 9 files changed, 270 insertions(+), 330 deletions(-) -- 2.43.0

2 11