October 2024 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] drm/amd/display: Check gpio_id before used as array index
by Zeng Heng 08 Oct '24

08 Oct '24

From: Alex Hung <alex.hung(a)amd.com> mainline inclusion from stable-v6.6.50 commit 08e7755f754e3d2cef7d3a7da538d33526bd6f7c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAU9MK CVE: CVE-2024-46818 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 2a5626eeb3b5eec7a36886f9556113dd93ec8ed6 ] [WHY & HOW] GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore should be checked in advance. This fixes 5 OVERRUN issues reported by Coverity. Reviewed-by: Harry Wentland <harry.wentland(a)amd.com> Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Alex Hung <alex.hung(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c index 3ede6e02c3a7..2f8ca831afa2 100644 --- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c +++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c @@ -239,6 +239,9 @@ static bool is_pin_busy( enum gpio_id id, uint32_t en) { + if (id == GPIO_ID_UNKNOWN) + return false; + return service->busyness[id][en]; } @@ -247,6 +250,9 @@ static void set_pin_busy( enum gpio_id id, uint32_t en) { + if (id == GPIO_ID_UNKNOWN) + return; + service->busyness[id][en] = true; } @@ -255,6 +261,9 @@ static void set_pin_free( enum gpio_id id, uint32_t en) { + if (id == GPIO_ID_UNKNOWN) + return; + service->busyness[id][en] = false; } @@ -263,7 +272,7 @@ enum gpio_result dal_gpio_service_lock( enum gpio_id id, uint32_t en) { - if (!service->busyness[id]) { + if (id != GPIO_ID_UNKNOWN && !service->busyness[id]) { ASSERT_CRITICAL(false); return GPIO_RESULT_OPEN_FAILED; } @@ -277,7 +286,7 @@ enum gpio_result dal_gpio_service_unlock( enum gpio_id id, uint32_t en) { - if (!service->busyness[id]) { + if (id != GPIO_ID_UNKNOWN && !service->busyness[id]) { ASSERT_CRITICAL(false); return GPIO_RESULT_OPEN_FAILED; } -- 2.25.1

2 1

[PATCH OLK-6.6] drm/amd/display: Check gpio_id before used as array index
by Zeng Heng 08 Oct '24

08 Oct '24

From: Alex Hung <alex.hung(a)amd.com> mainline inclusion from stable-v6.6.50 commit 2a5626eeb3b5eec7a36886f9556113dd93ec8ed6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAU9MK CVE: CVE-2024-46818 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 2a5626eeb3b5eec7a36886f9556113dd93ec8ed6 ] [WHY & HOW] GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore should be checked in advance. This fixes 5 OVERRUN issues reported by Coverity. Reviewed-by: Harry Wentland <harry.wentland(a)amd.com> Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Alex Hung <alex.hung(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c index 3ede6e02c3a7..2f8ca831afa2 100644 --- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c +++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c @@ -239,6 +239,9 @@ static bool is_pin_busy( enum gpio_id id, uint32_t en) { + if (id == GPIO_ID_UNKNOWN) + return false; + return service->busyness[id][en]; } @@ -247,6 +250,9 @@ static void set_pin_busy( enum gpio_id id, uint32_t en) { + if (id == GPIO_ID_UNKNOWN) + return; + service->busyness[id][en] = true; } @@ -255,6 +261,9 @@ static void set_pin_free( enum gpio_id id, uint32_t en) { + if (id == GPIO_ID_UNKNOWN) + return; + service->busyness[id][en] = false; } @@ -263,7 +272,7 @@ enum gpio_result dal_gpio_service_lock( enum gpio_id id, uint32_t en) { - if (!service->busyness[id]) { + if (id != GPIO_ID_UNKNOWN && !service->busyness[id]) { ASSERT_CRITICAL(false); return GPIO_RESULT_OPEN_FAILED; } @@ -277,7 +286,7 @@ enum gpio_result dal_gpio_service_unlock( enum gpio_id id, uint32_t en) { - if (!service->busyness[id]) { + if (id != GPIO_ID_UNKNOWN && !service->busyness[id]) { ASSERT_CRITICAL(false); return GPIO_RESULT_OPEN_FAILED; } -- 2.25.1

2 1

[PATCH OLK-6.6] cppc_cpufreq: Fix possible null pointer dereference
by Liu Mingrui 08 Oct '24

08 Oct '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit f84b9b25d045e67a7eee5e73f21278c8ab06713c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA74DQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit cf7de25878a1f4508c69dc9f6819c21ba177dbfe ] cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from different places with various parameters. So cpufreq_cpu_get() can return null as 'policy' in some circumstances. Fix this bug by adding null return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/cpufreq/cppc_cpufreq.c [Context conflict] Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/cpufreq/cppc_cpufreq.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index 66e8c850e6f2..eb4e27a4d192 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -878,10 +878,15 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int cpu) { struct fb_ctr_pair fb_ctrs = { .cpu = cpu, }; struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); - struct cppc_cpudata *cpu_data = policy->driver_data; + struct cppc_cpudata *cpu_data; u64 delivered_perf; int ret; + if (!policy) + return -ENODEV; + + cpu_data = policy->driver_data; + cpufreq_cpu_put(policy); if (cpu_has_amu_feat(cpu)) @@ -961,10 +966,15 @@ static struct cpufreq_driver cppc_cpufreq_driver = { static unsigned int hisi_cppc_cpufreq_get_rate(unsigned int cpu) { struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); - struct cppc_cpudata *cpu_data = policy->driver_data; + struct cppc_cpudata *cpu_data; u64 desired_perf; int ret; + if (!policy) + return -ENODEV; + + cpu_data = policy->driver_data; + cpufreq_cpu_put(policy); ret = cppc_get_desired_perf(cpu, &desired_perf); -- 2.25.1

2 1

[PATCH OLK-6.6] perf/x86/intel: Limit the period on Haswell
by Li Huafei 08 Oct '24

08 Oct '24

From: Kan Liang <kan.liang(a)linux.intel.com> stable inclusion from stable-v6.6.51 commit 0eaf812aa1506704f3b78be87036860e5d0fe81d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IR511 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b upstream. Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW. HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far. Fixes: 3a632cb229bf ("perf/x86/intel: Add simple Haswell PMU support") Reported-by: Li Huafei <lihuafei1(a)huawei.com> Suggested-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20240819183004.3132920-1-kan.liang@linux.intel.… Closes: https://lore.kernel.org/lkml/20240729223328.327835-1-lihuafei1@huawei.com/ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: arch/x86/events/intel/core.c [ Context conflict due to the backported commit b0560bfd4b70 ("perf/x86/intel: Clean up the hybrid CPU type handling code"). ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- arch/x86/events/intel/core.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 8b8e9189fd41..e2c1c51d8a01 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4520,6 +4520,25 @@ static enum hybrid_cpu_type adl_get_hybrid_cpu_type(void) return HYBRID_INTEL_CORE; } +static inline bool erratum_hsw11(struct perf_event *event) +{ + return (event->hw.config & INTEL_ARCH_EVENT_MASK) == + X86_CONFIG(.event=0xc0, .umask=0x01); +} + +/* + * The HSW11 requires a period larger than 100 which is the same as the BDM11. + * A minimum period of 128 is enforced as well for the INST_RETIRED.ALL. + * + * The message 'interrupt took too long' can be observed on any counter which + * was armed with a period < 32 and two events expired in the same NMI. + * A minimum period of 32 is enforced for the rest of the events. + */ +static void hsw_limit_period(struct perf_event *event, s64 *left) +{ + *left = max(*left, erratum_hsw11(event) ? 128 : 32); +} + /* * Broadwell: * @@ -4537,8 +4556,7 @@ static enum hybrid_cpu_type adl_get_hybrid_cpu_type(void) */ static void bdw_limit_period(struct perf_event *event, s64 *left) { - if ((event->hw.config & INTEL_ARCH_EVENT_MASK) == - X86_CONFIG(.event=0xc0, .umask=0x01)) { + if (erratum_hsw11(event)) { if (*left < 128) *left = 128; *left &= ~0x3fULL; @@ -6598,6 +6616,7 @@ __init int intel_pmu_init(void) x86_pmu.hw_config = hsw_hw_config; x86_pmu.get_event_constraints = hsw_get_event_constraints; + x86_pmu.limit_period = hsw_limit_period; x86_pmu.lbr_double_abort = true; extra_attr = boot_cpu_has(X86_FEATURE_RTM) ? hsw_format_attr : nhm_format_attr; -- 2.25.1

2 1

[PATCH OLK-5.10] perf/x86/intel: Limit the period on Haswell
by Li Huafei 08 Oct '24

08 Oct '24

From: Kan Liang <kan.liang(a)linux.intel.com> mainline inclusion from mainline-v6.11-rc7 commit 25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAR511 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW. HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far. Fixes: 3a632cb229bf ("perf/x86/intel: Add simple Haswell PMU support") Reported-by: Li Huafei <lihuafei1(a)huawei.com> Suggested-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20240819183004.3132920-1-kan.liang@linux.intel.… Closes: https://lore.kernel.org/lkml/20240729223328.327835-1-lihuafei1@huawei.com/ Conflicts: arch/x86/events/intel/core.c [ Adapted x86_pmu::limit_period signature due to commit 28f0f3c44b5c (“perf/x86: Change x86_pmu::limit_period signature”) not backported. ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- arch/x86/events/intel/core.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 4372ed2d1637..1786e8d85b6b 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4414,6 +4414,25 @@ static u8 adl_get_hybrid_cpu_type(void) return hybrid_big; } +static inline bool erratum_hsw11(struct perf_event *event) +{ + return (event->hw.config & INTEL_ARCH_EVENT_MASK) == + X86_CONFIG(.event=0xc0, .umask=0x01); +} + +/* + * The HSW11 requires a period larger than 100 which is the same as the BDM11. + * A minimum period of 128 is enforced as well for the INST_RETIRED.ALL. + * + * The message 'interrupt took too long' can be observed on any counter which + * was armed with a period < 32 and two events expired in the same NMI. + * A minimum period of 32 is enforced for the rest of the events. + */ +static u64 hsw_limit_period(struct perf_event *event, u64 left) +{ + return max(left, erratum_hsw11(event) ? 128ULL : 32ULL); +} + /* * Broadwell: * @@ -4431,8 +4450,7 @@ static u8 adl_get_hybrid_cpu_type(void) */ static u64 bdw_limit_period(struct perf_event *event, u64 left) { - if ((event->hw.config & INTEL_ARCH_EVENT_MASK) == - X86_CONFIG(.event=0xc0, .umask=0x01)) { + if (erratum_hsw11(event)) { if (left < 128) left = 128; left &= ~0x3fULL; @@ -6406,6 +6424,7 @@ __init int intel_pmu_init(void) x86_pmu.hw_config = hsw_hw_config; x86_pmu.get_event_constraints = hsw_get_event_constraints; + x86_pmu.limit_period = hsw_limit_period; x86_pmu.lbr_double_abort = true; extra_attr = boot_cpu_has(X86_FEATURE_RTM) ? hsw_format_attr : nhm_format_attr; -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 9625/23811] drivers/soundwire/bus_type.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 08 Oct '24

08 Oct '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 5c63bd0fa5e86474d30ecd06d67f2393de081434 commit: fe38a6fef0e5f4ba9c21d3e26381987519b7edc7 [9625/23811] soundwire: fix regmap dependencies and align with other serial links config: x86_64-buildonly-randconfig-003-20240925 (https://download.01.org/0day-ci/archive/20241008/202410080128.3Ornv3xR-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241008/202410080128.3Ornv3xR-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410080128.3Ornv3xR-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/soundwire/bus_type.o: warning: objtool: missing symbol for section .init.text -- >> drivers/soundwire/intel.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 8557/23811] lib/test_sort.o: warning: objtool: missing symbol for section .text.unlikely
by kernel test robot 07 Oct '24

07 Oct '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 5c63bd0fa5e86474d30ecd06d67f2393de081434 commit: 775947c125d5bd6e00e0dcf9d12c57fd5d44d07f [8557/23811] asm-generic: fix -Wtype-limits compiler warnings config: x86_64-buildonly-randconfig-003-20240925 (https://download.01.org/0day-ci/archive/20241007/202410071411.kGlEzJT5-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241007/202410071411.kGlEzJT5-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410071411.kGlEzJT5-lkp@intel.com/ All warnings (new ones prefixed by >>): >> lib/test_sort.o: warning: objtool: missing symbol for section .text.unlikely -- >> lib/test_list_sort.o: warning: objtool: missing symbol for section .text.unlikely -- >> lib/test_printf.o: warning: objtool: missing symbol for section .text.unlikely -- >> drivers/hwmon/coretemp.o: warning: objtool: missing symbol for section .text.unlikely -- >> drivers/hsi/hsi_boardinfo.o: warning: objtool: missing symbol for section .text.unlikely -- drivers/mtd/nand/raw/diskonchip.c: In function 'DoC_Delay': drivers/mtd/nand/raw/diskonchip.c:220:23: warning: variable 'dummy' set but not used [-Wunused-but-set-variable] 220 | volatile char dummy; | ^~~~~ drivers/mtd/nand/raw/diskonchip.c: In function 'doc200x_calculate_ecc': drivers/mtd/nand/raw/diskonchip.c:845:13: warning: variable 'emptymatch' set but not used [-Wunused-but-set-variable] 845 | int emptymatch = 1; | ^~~~~~~~~~ In file included from include/linux/kernel.h:14, from drivers/mtd/nand/raw/diskonchip.c:18: drivers/mtd/nand/raw/diskonchip.c: In function 'doc_probe': include/linux/printk.h:348:9: warning: this statement may fall through [-Wimplicit-fallthrough=] 348 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/mtd/nand/raw/diskonchip.c:1497:25: note: in expansion of macro 'pr_err' 1497 | pr_err("DiskOnChip Millennium Plus 32MB is not supported, ignoring.\n"); | ^~~~~~ drivers/mtd/nand/raw/diskonchip.c:1498:17: note: here 1498 | default: | ^~~~~~~ >> drivers/mtd/nand/raw/diskonchip.o: warning: objtool: missing symbol for section .text.unlikely -- kernel/events/hw_breakpoint.c:84:12: warning: no previous prototype for 'hw_breakpoint_weight' [-Wmissing-prototypes] 84 | __weak int hw_breakpoint_weight(struct perf_event *bp) | ^~~~~~~~~~~~~~~~~~~~ kernel/events/hw_breakpoint.c:232:13: warning: no previous prototype for 'arch_unregister_hw_breakpoint' [-Wmissing-prototypes] 232 | __weak void arch_unregister_hw_breakpoint(struct perf_event *bp) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel/events/hw_breakpoint.c:458: warning: Function parameter or member 'context' not described in 'register_user_hw_breakpoint' kernel/events/hw_breakpoint.c:557: warning: Function parameter or member 'context' not described in 'register_wide_hw_breakpoint' >> kernel/events/hw_breakpoint.o: warning: objtool: missing symbol for section .text.unlikely -- >> drivers/thermal/intel_powerclamp.o: warning: objtool: missing symbol for section .text.unlikely -- >> drivers/clk/bcm/clk-iproc-asiu.o: warning: objtool: missing symbol for section .text.unlikely -- >> drivers/clk/renesas/clk-div6.o: warning: objtool: missing symbol for section .text.unlikely -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] dma-buf: heaps: Fix off-by-one in CMA heap fault handler
by Xiongfeng Wang 07 Oct '24

07 Oct '24

From: "T.J. Mercier" <tjmercier(a)google.com> stable inclusion from stable-v6.6.52 commit eb7fc8b65cea22f9038c52398c8b22849e9620ea category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAU9M8 CVE: CVE-2024-46852 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ea5ff5d351b520524019f7ff7f9ce418de2dad87 upstream. Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dma_buf_mmap_internal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping. Reported-by: Xingyu Jin <xingyuj(a)google.com> Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Cc: stable(a)vger.kernel.org # Applicable >= 5.10. Needs adjustments only for 5.10. Signed-off-by: T.J. Mercier <tjmercier(a)google.com> Acked-by: John Stultz <jstultz(a)google.com> Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240830192627.2546033-1-tjme… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> --- drivers/dma-buf/heaps/cma_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index ee899f8e6721..bea7e574f916 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -165,7 +165,7 @@ static vm_fault_t cma_heap_vm_fault(struct vm_fault *vmf) struct vm_area_struct *vma = vmf->vma; struct cma_heap_buffer *buffer = vma->vm_private_data; - if (vmf->pgoff > buffer->pagecount) + if (vmf->pgoff >= buffer->pagecount) return VM_FAULT_SIGBUS; vmf->page = buffer->pages[vmf->pgoff]; -- 2.20.1

2 1

[openeuler:openEuler-1.0-LTS 8452/23811] kernel/ktask.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 07 Oct '24

07 Oct '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 5c63bd0fa5e86474d30ecd06d67f2393de081434 commit: c48676ef6b6f9cb8497d6264ae9ff71b87630337 [8452/23811] ktask: multithread CPU-intensive kernel work config: x86_64-buildonly-randconfig-003-20240925 (https://download.01.org/0day-ci/archive/20241007/202410070443.gzxmSrdz-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241007/202410070443.gzxmSrdz-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410070443.gzxmSrdz-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/ktask.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 6661/23811] kernel/signal.o: warning: objtool: missing symbol for section .text.unlikely
by kernel test robot 06 Oct '24

06 Oct '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 5c63bd0fa5e86474d30ecd06d67f2393de081434 commit: f1bfcb97c436ae547c2889f3a25d74d85867e09f [6661/23811] kernel/signal.c: trace_signal_deliver when signal_group_exit config: x86_64-buildonly-randconfig-003-20240925 (https://download.01.org/0day-ci/archive/20241006/202410062155.gpahLOpk-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241006/202410062155.gpahLOpk-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410062155.gpahLOpk-lkp@intel.com/ All warnings (new ones prefixed by >>): include/linux/signal.h:128:9: note: here 128 | case 2: \ | ^~~~ include/linux/signal.h:141:1: note: in expansion of macro '_SIG_SET_BINOP' 141 | _SIG_SET_BINOP(sigorsets, _sig_or) | ^~~~~~~~~~~~~~ include/linux/signal.h:130:27: warning: this statement may fall through [-Wimplicit-fallthrough=] 130 | r->sig[1] = op(a1, b1); \ | ^ include/linux/signal.h:141:1: note: in expansion of macro '_SIG_SET_BINOP' 141 | _SIG_SET_BINOP(sigorsets, _sig_or) | ^~~~~~~~~~~~~~ include/linux/signal.h:131:9: note: here 131 | case 1: \ | ^~~~ include/linux/signal.h:141:1: note: in expansion of macro '_SIG_SET_BINOP' 141 | _SIG_SET_BINOP(sigorsets, _sig_or) | ^~~~~~~~~~~~~~ include/linux/signal.h: In function 'sigandsets': include/linux/signal.h:127:27: warning: this statement may fall through [-Wimplicit-fallthrough=] 127 | r->sig[2] = op(a2, b2); \ | ^ include/linux/signal.h:144:1: note: in expansion of macro '_SIG_SET_BINOP' 144 | _SIG_SET_BINOP(sigandsets, _sig_and) | ^~~~~~~~~~~~~~ include/linux/signal.h:128:9: note: here 128 | case 2: \ | ^~~~ include/linux/signal.h:144:1: note: in expansion of macro '_SIG_SET_BINOP' 144 | _SIG_SET_BINOP(sigandsets, _sig_and) | ^~~~~~~~~~~~~~ include/linux/signal.h:130:27: warning: this statement may fall through [-Wimplicit-fallthrough=] 130 | r->sig[1] = op(a1, b1); \ | ^ include/linux/signal.h:144:1: note: in expansion of macro '_SIG_SET_BINOP' 144 | _SIG_SET_BINOP(sigandsets, _sig_and) | ^~~~~~~~~~~~~~ include/linux/signal.h:131:9: note: here 131 | case 1: \ | ^~~~ include/linux/signal.h:144:1: note: in expansion of macro '_SIG_SET_BINOP' 144 | _SIG_SET_BINOP(sigandsets, _sig_and) | ^~~~~~~~~~~~~~ include/linux/signal.h: In function 'sigandnsets': include/linux/signal.h:127:27: warning: this statement may fall through [-Wimplicit-fallthrough=] 127 | r->sig[2] = op(a2, b2); \ | ^ include/linux/signal.h:147:1: note: in expansion of macro '_SIG_SET_BINOP' 147 | _SIG_SET_BINOP(sigandnsets, _sig_andn) | ^~~~~~~~~~~~~~ include/linux/signal.h:128:9: note: here 128 | case 2: \ | ^~~~ include/linux/signal.h:147:1: note: in expansion of macro '_SIG_SET_BINOP' 147 | _SIG_SET_BINOP(sigandnsets, _sig_andn) | ^~~~~~~~~~~~~~ include/linux/signal.h:130:27: warning: this statement may fall through [-Wimplicit-fallthrough=] 130 | r->sig[1] = op(a1, b1); \ | ^ include/linux/signal.h:147:1: note: in expansion of macro '_SIG_SET_BINOP' 147 | _SIG_SET_BINOP(sigandnsets, _sig_andn) | ^~~~~~~~~~~~~~ include/linux/signal.h:131:9: note: here 131 | case 1: \ | ^~~~ include/linux/signal.h:147:1: note: in expansion of macro '_SIG_SET_BINOP' 147 | _SIG_SET_BINOP(sigandnsets, _sig_andn) | ^~~~~~~~~~~~~~ kernel/signal.c: In function 'check_kill_permission': kernel/signal.c:830:34: warning: this statement may fall through [-Wimplicit-fallthrough=] 830 | if (!sid || sid == task_session(current)) | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel/signal.c:832:17: note: here 832 | default: | ^~~~~~~ include/linux/signal.h: In function 'signotset': include/linux/signal.h:159:29: warning: this statement may fall through [-Wimplicit-fallthrough=] 159 | set->sig[2] = op(set->sig[2]); \ | ^ include/linux/signal.h:169:1: note: in expansion of macro '_SIG_SET_OP' 169 | _SIG_SET_OP(signotset, _sig_not) | ^~~~~~~~~~~ include/linux/signal.h:160:9: note: here 160 | case 2: set->sig[1] = op(set->sig[1]); \ | ^~~~ include/linux/signal.h:169:1: note: in expansion of macro '_SIG_SET_OP' 169 | _SIG_SET_OP(signotset, _sig_not) | ^~~~~~~~~~~ include/linux/signal.h:160:29: warning: this statement may fall through [-Wimplicit-fallthrough=] 160 | case 2: set->sig[1] = op(set->sig[1]); \ | ^ include/linux/signal.h:169:1: note: in expansion of macro '_SIG_SET_OP' 169 | _SIG_SET_OP(signotset, _sig_not) | ^~~~~~~~~~~ include/linux/signal.h:161:9: note: here 161 | case 1: set->sig[0] = op(set->sig[0]); \ | ^~~~ include/linux/signal.h:169:1: note: in expansion of macro '_SIG_SET_OP' 169 | _SIG_SET_OP(signotset, _sig_not) | ^~~~~~~~~~~ >> kernel/signal.o: warning: objtool: missing symbol for section .text.unlikely -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

2024

2023

2022

2021

2020

2019

Kernel October 2024