- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 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 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