- Kernel - mailweb.openeuler.org

[OLK-5.10 0/2] CVE-2025-38180
by Yongqiang Liu 12 Aug '25

12 Aug '25

Eric Dumazet (2): net: atm: add lec_mutex net: atm: fix /proc/net/atm/lec handling net/atm/lec.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- 2.43.0

1 2

[OLK-6.6 0/1] CVE-2025-38211
by Yongqiang Liu 12 Aug '25

12 Aug '25

Shin'ichiro Kawasaki (1): RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction drivers/infiniband/core/iwcm.c | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) -- 2.43.0

1 1

[OLK-6.6 0/1] CVE-2025-38375
by Yongqiang Liu 12 Aug '25

12 Aug '25

Bui Quang Minh (1): virtio-net: ensure the received length does not exceed allocated size drivers/net/virtio_net.c | 38 ++++++++++++++++++++++++++++++++++---- 1 file changed, 34 insertions(+), 4 deletions(-) -- 2.43.0

1 1

[OLK-6.6 0/1] CVE-2025-38473
by Yongqiang Liu 12 Aug '25

12 Aug '25

Kuniyuki Iwashima (1): Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() net/bluetooth/l2cap_sock.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.43.0

1 1

[PATCH OLK-6.6 0/1] CVE-2025-38251
by Yongqiang Liu 12 Aug '25

12 Aug '25

Eric Dumazet (1): atm: clip: prevent NULL deref in clip_push() net/atm/clip.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10] powerpc/xive/spapr: correct bitmap allocation size
by Bowen You 12 Aug '25

12 Aug '25

From: Nathan Lynch <nathanl(a)linux.ibm.com> mainline inclusion from mainline-v5.19-rc5 commit 19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP6KY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------ kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency. Signed-off-by: Nathan Lynch <nathanl(a)linux.ibm.com> Reviewed-by: Cédric Le Goater <clg(a)kaod.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20220623182509.3985625-1-nathanl@linux.ibm.com Conflicts: arch/powerpc/sysdev/xive/spapr.c [context conflict, xive_irq_bitmap_remove_all function not merged.] Signed-off-by: Bowen You <youbowen2(a)huawei.com> --- arch/powerpc/sysdev/xive/spapr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c index 53cf14349d5e..4c95bfe8813b 100644 --- a/arch/powerpc/sysdev/xive/spapr.c +++ b/arch/powerpc/sysdev/xive/spapr.c @@ -55,7 +55,7 @@ static int xive_irq_bitmap_add(int base, int count) spin_lock_init(&xibm->lock); xibm->base = base; xibm->count = count; - xibm->bitmap = kzalloc(xibm->count, GFP_KERNEL); + xibm->bitmap = bitmap_zalloc(xibm->count, GFP_KERNEL); if (!xibm->bitmap) { kfree(xibm); return -ENOMEM; -- 2.34.1

2 1

[openeuler:OLK-6.6 2669/2669] drivers/net/ethernet/huawei/bma/edma_drv/edma_queue.c:330:5: warning: no previous prototype for function 'wait_done_dma_queue'
by kernel test robot 12 Aug '25

12 Aug '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 68ac72c2610cc9a280d47c6f733db0eff92efc15 commit: 85502a982830072aff2efa8b65f75c240b4d6181 [2669/2669] Huawei iBMA: Added support for Hi1712 Chip config: loongarch-allmodconfig (https://download.01.org/0day-ci/archive/20250812/202508121628.Gr4EiznB-lkp@…) compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121628.Gr4EiznB-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/202508121628.Gr4EiznB-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/net/ethernet/huawei/bma/edma_drv/edma_queue.c:330:5: warning: no previous prototype for function 'wait_done_dma_queue' [-Wmissing-prototypes] 330 | s32 wait_done_dma_queue(unsigned long timeout) | ^ drivers/net/ethernet/huawei/bma/edma_drv/edma_queue.c:330:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 330 | s32 wait_done_dma_queue(unsigned long timeout) | ^ | static 1 warning generated. vim +/wait_done_dma_queue +330 drivers/net/ethernet/huawei/bma/edma_drv/edma_queue.c 329 > 330 s32 wait_done_dma_queue(unsigned long timeout) 331 { 332 struct dma_ch_cq_s *p_cur_last_cq; 333 struct dma_ch_cq_s *p_dma_cq; 334 unsigned long end; 335 u32 sq_tail; 336 u32 sq_valid; 337 u32 cq_tail; 338 u32 cq_valid; 339 340 p_dma_cq = (struct dma_ch_cq_s *)((&get_bma_dev()->edma_host)->edma_cq_addr); 341 end = jiffies + timeout; 342 343 while (time_before(jiffies, end)) { 344 (void)get_dma_queue_sq_tail(&sq_tail); 345 (void)get_dma_queue_cq_tail(&cq_tail); 346 347 cq_valid = (cq_tail + CQ_DEPTH - 1) % (CQ_DEPTH); 348 p_cur_last_cq = &p_dma_cq[cq_valid]; 349 sq_valid = (sq_tail + SQ_DEPTH - 1) % (SQ_DEPTH); 350 BMA_LOG(DLOG_DEBUG, 351 "sq_tail %d, cq_tail %d, cq_valid %d, sq_valid %d, p_cur_last_cq->sqhd %d\n", 352 sq_tail, cq_tail, cq_valid, sq_valid, p_cur_last_cq->sqhd); 353 if (p_cur_last_cq->sqhd == sq_valid) { 354 set_dma_queue_cq_head(cq_valid); 355 return 0; 356 } 357 } 358 359 return -ETIMEDOUT; 360 } 361 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6 2669/2669] kernel/sched/debug.c:102:12: warning: no previous prototype for function 'is_prefer_numa'
by kernel test robot 12 Aug '25

12 Aug '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 263cf8eeb5316aeebd9d692e9966df029f65889f commit: 0f22304e62d360fce47988586d599e33895ccb01 [2669/2669] sched: Support NUMA parallel scheduling for multiple processes config: x86_64-buildonly-randconfig-001-20250812 (https://download.01.org/0day-ci/archive/20250812/202508121611.xU3A9CdS-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121611.xU3A9CdS-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/202508121611.xU3A9CdS-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from kernel/sched/build_utility.c:73: >> kernel/sched/debug.c:102:12: warning: no previous prototype for function 'is_prefer_numa' [-Wmissing-prototypes] 102 | int __weak is_prefer_numa(void) | ^ kernel/sched/debug.c:102:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 102 | int __weak is_prefer_numa(void) | ^ | static In file included from kernel/sched/build_utility.c:105: kernel/sched/isolation.c:134:46: error: use of undeclared identifier 'setup_max_cpus' 134 | if (first_cpu >= nr_cpu_ids || first_cpu >= setup_max_cpus) { | ^ 1 warning and 1 error generated. vim +/is_prefer_numa +102 kernel/sched/debug.c 101 > 102 int __weak is_prefer_numa(void) 103 { 104 return 0; 105 } 106 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] powerpc/xive/spapr: correct bitmap allocation size
by Bowen You 12 Aug '25

12 Aug '25

From: Nathan Lynch <nathanl(a)linux.ibm.com> mainline inclusion from mainline-v5.19-rc5 commit 19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP6KY Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------ kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency. Signed-off-by: Nathan Lynch <nathanl(a)linux.ibm.com> Reviewed-by: Cédric Le Goater <clg(a)kaod.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20220623182509.3985625-1-nathanl@linux.ibm.com Conflicts: arch/powerpc/sysdev/xive/spapr.c [context conflict, xive_irq_bitmap_remove_all function not merged.] Signed-off-by: Bowen You <youbowen2(a)huawei.com> --- arch/powerpc/sysdev/xive/spapr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c index 53cf14349d5e..4c95bfe8813b 100644 --- a/arch/powerpc/sysdev/xive/spapr.c +++ b/arch/powerpc/sysdev/xive/spapr.c @@ -55,7 +55,7 @@ static int xive_irq_bitmap_add(int base, int count) spin_lock_init(&xibm->lock); xibm->base = base; xibm->count = count; - xibm->bitmap = kzalloc(xibm->count, GFP_KERNEL); + xibm->bitmap = bitmap_zalloc(xibm->count, GFP_KERNEL); if (!xibm->bitmap) { kfree(xibm); return -ENOMEM; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 1755/1755] drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'VRM' not described in enum 'rpmh_regulator_type'
by kernel test robot 12 Aug '25

12 Aug '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: a7892155ca524e224cb2da85c85cc1bd4303179d commit: 46fc033eba42f5a4fb583b2ab53f0a9918468452 [1755/1755] regulator: add QCOM RPMh regulator driver config: x86_64-buildonly-randconfig-2002-20250811 (https://download.01.org/0day-ci/archive/20250812/202508121032.93R4tKQv-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508121032.93R4tKQv-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/202508121032.93R4tKQv-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'VRM' not described in enum 'rpmh_regulator_type' >> drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'XOB' not described in enum 'rpmh_regulator_type' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'vreg' not described in 'rpmh_regulator_init_vreg' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'dev' not described in 'rpmh_regulator_init_vreg' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'node' not described in 'rpmh_regulator_init_vreg' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'pmic_id' not described in 'rpmh_regulator_init_vreg' >> drivers/regulator/qcom-rpmh-regulator.c:402: warning: Function parameter or member 'pmic_rpmh_data' not described in 'rpmh_regulator_init_vreg' vim +33 drivers/regulator/qcom-rpmh-regulator.c 22 23 /** 24 * enum rpmh_regulator_type - supported RPMh accelerator types 25 * %VRM: RPMh VRM accelerator which supports voting on enable, voltage, 26 * and mode of LDO, SMPS, and BOB type PMIC regulators. 27 * %XOB: RPMh XOB accelerator which supports voting on the enable state 28 * of PMIC regulators. 29 */ 30 enum rpmh_regulator_type { 31 VRM, 32 XOB, > 33 }; 34 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0