- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/3] CVE-2024-58100
by Chen Zhongjin 05 Jun '25

05 Jun '25

Chen Zhongjin (1): bpf: Fix kabi breakage for changes_pkt_data in struct bpf_prog_aux Eduard Zingerman (2): bpf: check changes_pkt_data property for extension programs bpf: fix null dereference when computing changes_pkt_data of prog w/o subprogs include/linux/bpf.h | 1 + kernel/bpf/verifier.c | 19 +++++++++++++++---- 2 files changed, 16 insertions(+), 4 deletions(-) -- 2.25.1

2 4

[PATCH OLK-6.6] iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo
by Chen Zhongjin 05 Jun '25

05 Jun '25

From: Silvano Seva <s.seva(a)4sigma.it> stable inclusion from stable-v6.6.91 commit 9ce662851380fe2018e36e15c0bdcb1ad177ed95 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC992M CVE: CVE-2025-37969 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit 8114ef86e2058e2554111b793596f17bee23fa15 upstream. Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty. Fixes: 801a6e0af0c6 ("iio: imu: st_lsm6dsx: add support to LSM6DSO") Signed-off-by: Silvano Seva <s.seva(a)4sigma.it> Acked-by: Lorenzo Bianconi <lorenzo(a)kernel.org> Link: https://patch.msgid.link/20250311085030.3593-4-s.seva@4sigma.it Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c index 56b14afed769..b8119fa4768e 100644 --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c @@ -604,6 +604,9 @@ int st_lsm6dsx_read_tagged_fifo(struct st_lsm6dsx_hw *hw) if (!fifo_len) return 0; + if (!pattern_len) + pattern_len = ST_LSM6DSX_TAGGED_SAMPLE_SIZE; + for (read_len = 0; read_len < fifo_len; read_len += pattern_len) { err = st_lsm6dsx_read_block(hw, ST_LSM6DSX_REG_FIFO_OUT_TAG_ADDR, -- 2.25.1

2 1

[PATCH OLK-6.6 V1] pds_core: remove write-after-free of client_id
by Wang Tao 05 Jun '25

05 Jun '25

From: Shannon Nelson <shannon.nelson(a)amd.com> stable inclusion from stable-v6.6.90 commit 9b467c5bcdb45a41d2a49fbb9ffca73d1380e99b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC9921 CVE: CVE-2025-37916 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dfd76010f8e821b66116dec3c7d90dd2403d1396 ] A use-after-free error popped up in stress testing: [Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47): [Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core] [Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70 [Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180 [Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80 [Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0 [Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80 The actual device uninit usually happens on a separate thread scheduled after this code runs, but there is no guarantee of order of thread execution, so this could be a problem. There's no actual need to clear the client_id at this point, so simply remove the offending code. Fixes: 10659034c622 ("pds_core: add the aux client API") Signed-off-by: Shannon Nelson <shannon.nelson(a)amd.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250425203857.71547-1-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/net/ethernet/amd/pds_core/auxbus.c [Some optimization patches restructured the method in linux-v6.6.90, but HULK-6.6 did not merge, so there is a conflict.] Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- drivers/net/ethernet/amd/pds_core/auxbus.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/amd/pds_core/auxbus.c b/drivers/net/ethernet/amd/pds_core/auxbus.c index fd1a5149c003..c3dae03bb94a 100644 --- a/drivers/net/ethernet/amd/pds_core/auxbus.c +++ b/drivers/net/ethernet/amd/pds_core/auxbus.c @@ -187,7 +187,6 @@ int pdsc_auxbus_dev_del(struct pdsc *cf, struct pdsc *pf) pds_client_unregister(pf, padev->client_id); auxiliary_device_delete(&padev->aux_dev); auxiliary_device_uninit(&padev->aux_dev); - padev->client_id = 0; } pf->vfs[cf->vf_id].padev = NULL; -- 2.34.1

2 1

[openeuler:OLK-6.6 2357/2357] arch/arm64/kernel/idle.c:54:1: sparse: sparse: symbol '__pcpu_scope_contexts' was not declared. Should it be static?
by kernel test robot 05 Jun '25

05 Jun '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 3160da23afe10e66040ac00ed17174cb467c79b3 commit: 7f2e02718bba28c9969b7f8d5d53301abab7f760 [2357/2357] arm64: entry: Support hardware xcall and xint config: arm64-randconfig-r123-20250605 (https://download.01.org/0day-ci/archive/20250605/202506051337.VIeB2SKc-lkp@…) compiler: aarch64-linux-gcc (GCC) 10.5.0 reproduce: (https://download.01.org/0day-ci/archive/20250605/202506051337.VIeB2SKc-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/202506051337.VIeB2SKc-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> arch/arm64/kernel/idle.c:54:1: sparse: sparse: symbol '__pcpu_scope_contexts' was not declared. Should it be static? vim +/__pcpu_scope_contexts +54 arch/arm64/kernel/idle.c 53 > 54 DEFINE_PER_CPU_ALIGNED(struct arm_cpuidle_xcall_xint_context, contexts); 55 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6 2357/2357] mm/mem_sampling.c:293:1: sparse: sparse: symbol 'mm_damon_mem_sampling' was not declared. Should it be static?
by kernel test robot 05 Jun '25

05 Jun '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 3160da23afe10e66040ac00ed17174cb467c79b3 commit: 2e9ef6c3ea086c85d489898471e527aeb3f7460b [2357/2357] mm/damon/vaddr: Support hardware-assisted memory access sampling config: arm64-randconfig-r123-20250605 (https://download.01.org/0day-ci/archive/20250605/202506051214.xnjA9eFd-lkp@…) compiler: aarch64-linux-gcc (GCC) 10.5.0 reproduce: (https://download.01.org/0day-ci/archive/20250605/202506051214.xnjA9eFd-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/202506051214.xnjA9eFd-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) mm/mem_sampling.c:48:33: sparse: sparse: symbol 'mem_sampling_saved_state' was not declared. Should it be static? mm/mem_sampling.c:61:1: sparse: sparse: symbol 'mem_sampling_record_cb_list' was not declared. Should it be static? mm/mem_sampling.c:69:6: sparse: sparse: symbol 'mem_sampling_record_cb_register' was not declared. Should it be static? mm/mem_sampling.c:86:6: sparse: sparse: symbol 'mem_sampling_record_cb_unregister' was not declared. Should it be static? >> mm/mem_sampling.c:293:1: sparse: sparse: symbol 'mm_damon_mem_sampling' was not declared. Should it be static? vim +/mm_damon_mem_sampling +293 mm/mem_sampling.c 292 > 293 DEFINE_STATIC_KEY_FALSE(mm_damon_mem_sampling); 294 #ifdef CONFIG_DAMON_MEM_SAMPLING 295 static void damon_mem_sampling_record_cb(struct mem_sampling_record *record) 296 { 297 struct damon_mem_sampling_fifo *damon_fifo; 298 struct damon_mem_sampling_record domon_record; 299 struct task_struct *task = NULL; 300 struct mm_struct *mm; 301 302 /* Discard kernel address accesses */ 303 if (record->virt_addr & (1UL << 63)) 304 return; 305 306 task = find_get_task_by_vpid((pid_t)record->context_id); 307 if (!task) 308 return; 309 310 mm = get_task_mm(task); 311 put_task_struct(task); 312 if (!mm) 313 return; 314 315 damon_fifo = mm->damon_fifo; 316 mmput(mm); 317 318 domon_record.vaddr = record->virt_addr; 319 320 /* only the proc under monitor now has damon_fifo */ 321 if (damon_fifo) { 322 if (kfifo_is_full(&damon_fifo->rx_kfifo)) 323 return; 324 325 kfifo_in_locked(&damon_fifo->rx_kfifo, &domon_record, 326 sizeof(struct damon_mem_sampling_record), 327 &damon_fifo->rx_kfifo_lock); 328 return; 329 } 330 } 331 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 1365/1365] drivers/acpi/cppc_acpi.c:614:3-8: WARNING: NULL check before some freeing functions is not needed.
by kernel test robot 05 Jun '25

05 Jun '25

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: f86f8706481a23ecd781d2d13c3815a7fb4cc312 commit: b8815fbbe89b0d15fa3296c3e57d2197a92f5bc0 [1365/1365] ACPI: CPPC: Fix cppc_cpufreq_init failed in CPU Hotplug situation config: x86_64-randconfig-102-20250103 (https://download.01.org/0day-ci/archive/20250605/202506051103.QJTAn6J7-lkp@…) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) 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/202506051103.QJTAn6J7-lkp@intel.com/ cocci warnings: (new ones prefixed by >>) >> drivers/acpi/cppc_acpi.c:614:3-8: WARNING: NULL check before some freeing functions is not needed. vim +614 drivers/acpi/cppc_acpi.c 576 577 int acpi_get_psd_map(struct cppc_cpudata **all_cpu_data) 578 { 579 struct cpc_desc **cpc_pptr, *cpc_ptr; 580 int parsed_core_num = 0; 581 int i, ret; 582 583 cpc_pptr = kcalloc(num_possible_cpus(), sizeof(void *), GFP_KERNEL); 584 if (!cpc_pptr) 585 return -ENOMEM; 586 for_each_possible_cpu(i) { 587 cpc_pptr[i] = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); 588 if (!cpc_pptr[i]) { 589 ret = -ENOMEM; 590 goto out; 591 } 592 } 593 594 /* 595 * We can not use acpi_get_devices() to walk the processor devices 596 * because some processor device is not present. 597 */ 598 ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 599 ACPI_UINT32_MAX, acpi_parse_cpc, NULL, 600 cpc_pptr, (void **)&parsed_core_num); 601 if (ret) 602 goto out; 603 if (parsed_core_num != num_possible_cpus()) { 604 ret = -EINVAL; 605 goto out; 606 } 607 608 ret = __acpi_get_psd_map(all_cpu_data, cpc_pptr); 609 610 out: 611 for_each_possible_cpu(i) { 612 cpc_ptr = cpc_pptr[i]; 613 if (cpc_ptr) > 614 kfree(cpc_ptr); 615 } 616 kfree(cpc_pptr); 617 618 return ret; 619 } 620 EXPORT_SYMBOL_GPL(acpi_get_psd_map); 621 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] ftrace: Fix preemption accounting for stacktrace trigger command
by Tengda Wu 05 Jun '25

05 Jun '25

From: pengdonglin <pengdonglin(a)xiaomi.com> stable inclusion from stable-6.6.93 commit fa75d941b104e7248e0b5e532fc92c202203eb05 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICCR8Z Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e333332657f615ac2b55aa35565c4a882018bbe9 upstream. When using the stacktrace trigger command to trace syscalls, the preemption count was consistently reported as 1 when the system call event itself had 0 ("."). For example: root@ubuntu22-vm:/sys/kernel/tracing/events/syscalls/sys_enter_read $ echo stacktrace > trigger $ echo 1 > enable sshd-416 [002] ..... 232.864910: sys_read(fd: a, buf: 556b1f3221d0, count: 8000) sshd-416 [002] ...1. 232.864913: <stack trace> => ftrace_syscall_enter => syscall_trace_enter => do_syscall_64 => entry_SYSCALL_64_after_hwframe The root cause is that the trace framework disables preemption in __DO_TRACE before invoking the trigger callback. Use the tracing_gen_ctx_dec() that will accommodate for the increase of the preemption count in __DO_TRACE when calling the callback. The result is the accurate reporting of: sshd-410 [004] ..... 210.117660: sys_read(fd: 4, buf: 559b725ba130, count: 40000) sshd-410 [004] ..... 210.117662: <stack trace> => ftrace_syscall_enter => syscall_trace_enter => do_syscall_64 => entry_SYSCALL_64_after_hwframe Cc: stable(a)vger.kernel.org Fixes: ce33c845b030c ("tracing: Dump stacktrace trigger to the corresponding instance") Link: https://lore.kernel.org/20250512094246.1167956-1-dolinux.peng@gmail.com Signed-off-by: pengdonglin <dolinux.peng(a)gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/trace_events_trigger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c index 76abc9a45f97..2c233c0d38fa 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -1554,7 +1554,7 @@ stacktrace_trigger(struct event_trigger_data *data, struct trace_event_file *file = data->private_data; if (file) - __trace_stack(file->tr, tracing_gen_ctx(), STACK_SKIP); + __trace_stack(file->tr, tracing_gen_ctx_dec(), STACK_SKIP); else trace_dump_stack(STACK_SKIP); } -- 2.34.1

2 1

[openeuler:OLK-6.6 2357/2357] mm/mem_sampling.c:38:33: sparse: sparse: symbol 'mem_sampling_saved_state' was not declared. Should it be static?
by kernel test robot 05 Jun '25

05 Jun '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 3160da23afe10e66040ac00ed17174cb467c79b3 commit: 02f32cc0235e33f7fc3e4910a80d386bc600935c [2357/2357] mm/mem_sampling:: Add proc and cmdline interface to control sampling enable config: arm64-randconfig-r123-20250605 (https://download.01.org/0day-ci/archive/20250605/202506051116.A1nDI3LD-lkp@…) compiler: aarch64-linux-gcc (GCC) 10.5.0 reproduce: (https://download.01.org/0day-ci/archive/20250605/202506051116.A1nDI3LD-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/202506051116.A1nDI3LD-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> mm/mem_sampling.c:38:33: sparse: sparse: symbol 'mem_sampling_saved_state' was not declared. Should it be static? mm/mem_sampling.c:51:1: sparse: sparse: symbol 'mem_sampling_record_cb_list' was not declared. Should it be static? mm/mem_sampling.c:53:6: sparse: sparse: symbol 'mem_sampling_record_cb_register' was not declared. Should it be static? mm/mem_sampling.c:70:6: sparse: sparse: symbol 'mem_sampling_record_cb_unregister' was not declared. Should it be static? mm/mem_sampling.c:83:1: sparse: sparse: symbol 'mem_sampling_access_hints' was not declared. Should it be static? vim +/mem_sampling_saved_state +38 mm/mem_sampling.c 32 33 enum mem_sampling_saved_state_e { 34 MEM_SAMPLING_STATE_ENABLE, 35 MEM_SAMPLING_STATE_DISABLE, 36 MEM_SAMPLING_STATE_EMPTY, 37 }; > 38 enum mem_sampling_saved_state_e mem_sampling_saved_state = MEM_SAMPLING_STATE_EMPTY; 39 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] vgacon: Add check for vc_origin address range in vgacon_scroll()
by Yi Yang 05 Jun '25

05 Jun '25

From: GONG Ruiqi <gongruiqi1(a)huawei.com> mainline inclusion from mainline-v6.16-rc1 commit 864f9963ec6b4b76d104d595ba28110b87158003 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC48UF CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Our in-house Syzkaller reported the following BUG (twice), which we believed was the same issue with [1]: ================================================================== BUG: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393 ... Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364 print_report+0xba/0x280 mm/kasan/report.c:475 kasan_report+0xa9/0xe0 mm/kasan/report.c:588 vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline] vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690 vfs_write+0x219/0x960 fs/read_write.c:584 ksys_write+0x12e/0x260 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ... </TASK> Allocated by task 5614: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383 kasan_kmalloc include/linux/kasan.h:201 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc+0x62/0x140 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] kzalloc include/linux/slab.h:721 [inline] vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193 vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007 vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031 con_font_set drivers/tty/vt/vt.c:4628 [inline] con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675 vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474 vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 __fput_sync+0x4c/0x60 fs/file_table.c:465 __do_sys_close fs/open.c:1580 [inline] __se_sys_close+0x68/0xd0 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 task_work_run+0x154/0x240 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:45 [inline] do_exit+0x8e5/0x1320 kernel/exit.c:874 do_group_exit+0xcd/0x280 kernel/exit.c:1023 get_signal+0x1675/0x1850 kernel/signal.c:2905 arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218 do_syscall_64+0x66/0x110 arch/x86/entry/common.c:87 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The buggy address belongs to the object at ffff88800f5be000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 2656 bytes to the right of allocated 1280-byte region [ffff88800f5be000, ffff88800f5be500) ... Memory state around the buggy address: ffff88800f5bee00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bee80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800f5bef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88800f5bef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bf000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== By analyzing the vmcore, we found that vc->vc_origin was somehow placed one line prior to vc->vc_screenbuf when vc was in KD_TEXT mode, and further writings to /dev/vcs caused out-of-bounds reads (and writes right after) in vcs_write_buf_noattr(). Our further experiments show that in most cases, vc->vc_origin equals to vga_vram_base when the console is in KD_TEXT mode, and it's around vc->vc_screenbuf for the KD_GRAPHICS mode. But via triggerring a TIOCL_SETVESABLANK ioctl beforehand, we can make vc->vc_origin be around vc->vc_screenbuf while the console is in KD_TEXT mode, and then by writing the special 'ESC M' control sequence to the tty certain times (depends on the value of `vc->state.y - vc->vc_top`), we can eventually move vc->vc_origin prior to vc->vc_screenbuf. Here's the PoC, tested on QEMU: ``` int main() { const int RI_NUM = 10; // should be greater than `vc->state.y - vc->vc_top` int tty_fd, vcs_fd; const char *tty_path = "/dev/tty0"; const char *vcs_path = "/dev/vcs"; const char escape_seq[] = "\x1bM"; // ESC + M const char trigger_seq[] = "Let's trigger an OOB write."; struct vt_sizes vt_size = { 70, 2 }; int blank = TIOCL_BLANKSCREEN; tty_fd = open(tty_path, O_RDWR); char vesa_mode[] = { TIOCL_SETVESABLANK, 1 }; ioctl(tty_fd, TIOCLINUX, vesa_mode); ioctl(tty_fd, TIOCLINUX, &blank); ioctl(tty_fd, VT_RESIZE, &vt_size); for (int i = 0; i < RI_NUM; ++i) write(tty_fd, escape_seq, sizeof(escape_seq) - 1); vcs_fd = open(vcs_path, O_RDWR); write(vcs_fd, trigger_seq, sizeof(trigger_seq)); close(vcs_fd); close(tty_fd); return 0; } ``` To solve this problem, add an address range validation check in vgacon_scroll(), ensuring vc->vc_origin never precedes vc_screenbuf. Reported-by: syzbot+9c09fda97a1a65ea859b(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9c09fda97a1a65ea859b [1] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Co-developed-by: Yi Yang <yiyang13(a)huawei.com> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> Signed-off-by: GONG Ruiqi <gongruiqi1(a)huawei.com> Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/video/console/vgacon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c index 4509d0547087..b0bf4e9e17f5 100644 --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -1194,7 +1194,7 @@ static bool vgacon_scroll(struct vc_data *c, unsigned int t, unsigned int b, c->vc_screenbuf_size - delta); c->vc_origin = vga_vram_end - c->vc_screenbuf_size; vga_rolled_over = 0; - } else + } else if (oldo - delta >= (unsigned long)c->vc_screenbuf) c->vc_origin -= delta; c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size; scr_memsetw((u16 *) (c->vc_origin), c->vc_video_erase_char, -- 2.25.1

2 1

[PATCH OLK-6.6] vxlan: vnifilter: Fix unlocked deletion of default FDB entry
by Wang Hai 05 Jun '25

05 Jun '25

From: Ido Schimmel <idosch(a)nvidia.com> stable inclusion from stable-v6.6.90 commit 3576e9a80b6c4381b01ce0cbaa07f5e92d4492ed category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC9926 CVE: CVE-2025-37921 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 087a9eb9e5978e3ba362e1163691e41097e8ca20 ] When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup"). Reproducer: # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0 Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it. [1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Call Trace: <TASK> __vxlan_fdb_delete+0xbe/0x560 vxlan_vni_delete_group+0x2ba/0x940 vxlan_vni_del.isra.0+0x15f/0x580 vxlan_process_vni_filter+0x38b/0x7b0 vxlan_vnifilter_process+0x3bb/0x510 rtnetlink_rcv_msg+0x2f7/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Signed-off-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor(a)blackwall.org> Link: https://patch.msgid.link/20250423145131.513029-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/net/vxlan/vxlan_vnifilter.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/vxlan/vxlan_vnifilter.c b/drivers/net/vxlan/vxlan_vnifilter.c index 6e6e9f05509a..06d19e90eadb 100644 --- a/drivers/net/vxlan/vxlan_vnifilter.c +++ b/drivers/net/vxlan/vxlan_vnifilter.c @@ -625,18 +625,24 @@ static void vxlan_vni_delete_group(struct vxlan_dev *vxlan, /* if per vni remote_ip not present, delete the * default dst remote_ip previously added for this vni */ if (!vxlan_addr_any(&vninode->remote_ip) || - !vxlan_addr_any(&dst->remote_ip)) + !vxlan_addr_any(&dst->remote_ip)) { + u32 hash_index = fdb_head_index(vxlan, all_zeros_mac, + vninode->vni); + + spin_lock_bh(&vxlan->hash_lock[hash_index]); __vxlan_fdb_delete(vxlan, all_zeros_mac, (vxlan_addr_any(&vninode->remote_ip) ? dst->remote_ip : vninode->remote_ip), vxlan->cfg.dst_port, vninode->vni, vninode->vni, dst->remote_ifindex, true); + spin_unlock_bh(&vxlan->hash_lock[hash_index]); + } if (vxlan->dev->flags & IFF_UP) { if (vxlan_addr_multicast(&vninode->remote_ip) && !vxlan_group_used(vn, vxlan, vninode->vni, &vninode->remote_ip, -- 2.17.1

2 1