January 2025 - Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] nbd: don't allow reconnect after disconnect
by Yu Kuai 23 Jan '25

23 Jan '25

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBGB8Q CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commi… ---------------------------------------- Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail. Fixes: b7aa3d39385d ("nbd: add a reconfigure netlink command") Reported-by: syzbot+6b0df248918b92c33e6a(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/675bfb65.050a0220.1a2d0d.0006.GAE@google.com/ Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Link: https://lore.kernel.org/r/20250103092859.3574648-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> --- drivers/block/nbd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index 9dbd7cb3df13..fa111ed7cdae 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -2166,6 +2166,7 @@ static void nbd_disconnect_and_put(struct nbd_device *nbd) flush_workqueue(nbd->recv_workq); nbd_clear_que(nbd); nbd->task_setup = NULL; + clear_bit(NBD_RT_BOUND, &nbd->config->runtime_flags); mutex_unlock(&nbd->config_lock); if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, -- 2.39.2

2 1

[openeuler:OLK-6.6] BUILD REGRESSION cd78f9c5f86e6865625e2d4640e63616a82fbd6c
by kernel test robot 23 Jan '25

23 Jan '25

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: cd78f9c5f86e6865625e2d4640e63616a82fbd6c !14884 um: Fix potential integer overflow during physmem setup Error/Warning (recently discovered and may have been fixed): https://lore.kernel.org/oe-kbuild-all/202501230201.ng7IvX9g-lkp@intel.com drivers/gpu/drm/phytium/phytium_pci.c:236:9: error: call to undeclared function 'pci_enable_msi'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] drivers/gpu/drm/phytium/phytium_pci.c:271:3: error: call to undeclared function 'pci_disable_msi'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | |-- block-blk-io-hierarchy-iodump.c:warning:no-previous-prototype-for-function-__bio_stage_hierarchy_start | |-- drivers-net-ethernet-huawei-hibifur-bifur_event.c:warning:no-previous-prototype-for-function-bifur_net_event_callback | |-- drivers-net-ethernet-huawei-hibifur-bifur_event.c:warning:no-previous-prototype-for-function-bifur_notify_all_vfs_link_changed | |-- drivers-net-ethernet-huawei-hibifur-bifur_event.c:warning:no-previous-prototype-for-function-bifur_notify_vf_link_status | |-- drivers-net-ethernet-huawei-hibifur-bifur_main.c:warning:no-previous-prototype-for-function-bifur_enable_disable_vf_all | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_alloc_proc_file | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_cmd_exec | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_file_write | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_free_knl_msg_buf | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_global_dev_close | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_global_dev_open | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_global_file_add | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_global_file_del | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_msg_copy_from_usr | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_msg_copy_to_usr | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_proc_write | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_dev_file_add | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_dev_file_del | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_dev_proc_build | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_dev_proc_destroy | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_proc_close | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_proc_open | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_vf_info_hold | `-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_vf_info_put |-- arm64-randconfig-003-20250123 | |-- drivers-gpu-drm-phytium-phytium_pci.c:error:call-to-undeclared-function-pci_disable_msi-ISO-C99-and-later-do-not-support-implicit-function-declarations | `-- drivers-gpu-drm-phytium-phytium_pci.c:error:call-to-undeclared-function-pci_enable_msi-ISO-C99-and-later-do-not-support-implicit-function-declarations |-- loongarch-allmodconfig | `-- drivers-irqchip-irq-loongson-eiointc.c:warning:unused-variable-cores |-- loongarch-allnoconfig | `-- drivers-irqchip-irq-loongson-eiointc.c:warning:unused-variable-cores |-- loongarch-allyesconfig | `-- drivers-irqchip-irq-loongson-eiointc.c:warning:unused-variable-cores |-- loongarch-randconfig-001-20250123 | `-- drivers-irqchip-irq-loongson-eiointc.c:warning:unused-variable-cores |-- loongarch-randconfig-002-20250123 | |-- drivers-irqchip-irq-loongson-eiointc.c:warning:unused-variable-cores | |-- kernel-sched-fair.c:warning:hundred_thousand-defined-but-not-used | `-- kernel-sched-fair.c:warning:one_thousand-defined-but-not-used |-- x86_64-allnoconfig | |-- include-linux-sched-signal.h:linux-kabi.h-is-included-more-than-once. | `-- samples-trace_events-trace_custom_sched.c:linux-version.h-not-needed. |-- x86_64-allyesconfig | |-- block-blk-io-hierarchy-iodump.c:warning:no-previous-prototype-for-function-__bio_stage_hierarchy_start | |-- drivers-net-ethernet-huawei-hibifur-bifur_event.c:warning:no-previous-prototype-for-function-bifur_net_event_callback | |-- drivers-net-ethernet-huawei-hibifur-bifur_event.c:warning:no-previous-prototype-for-function-bifur_notify_all_vfs_link_changed | |-- drivers-net-ethernet-huawei-hibifur-bifur_event.c:warning:no-previous-prototype-for-function-bifur_notify_vf_link_status | |-- drivers-net-ethernet-huawei-hibifur-bifur_main.c:warning:no-previous-prototype-for-function-bifur_enable_disable_vf_all | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_alloc_proc_file | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_cmd_exec | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_file_write | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_free_knl_msg_buf | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_global_dev_close | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_global_dev_open | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_global_file_add | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_global_file_del | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_msg_copy_from_usr | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_msg_copy_to_usr | |-- drivers-net-ethernet-huawei-hibifur-bifur_pfile.c:warning:no-previous-prototype-for-function-bifur_proc_write | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_dev_file_add | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_dev_file_del | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_dev_proc_build | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_dev_proc_destroy | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_proc_close | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_proc_open | |-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_vf_info_hold | `-- drivers-net-ethernet-huawei-hibifur-bifur_vf_mgr.c:warning:no-previous-prototype-for-function-bifur_vf_info_put `-- x86_64-buildonly-randconfig-002-20250123 |-- drivers-net-ethernet-nebula-matrix-nbl-nbl_core-nbl_dev_user.c:error:call-to-undeclared-function-eventfd_ctx_fileget-ISO-C99-and-later-do-not-support-implicit-function-declarations `-- drivers-net-ethernet-nebula-matrix-nbl-nbl_core-nbl_dev_user.c:error:incompatible-integer-to-pointer-conversion-assigning-to-struct-eventfd_ctx-from-int elapsed time: 889m configs tested: 19 configs skipped: 114 tested configs: arm64 allmodconfig clang-18 arm64 allnoconfig gcc-14.2.0 arm64 randconfig-001-20250123 gcc-14.2.0 arm64 randconfig-002-20250123 clang-20 arm64 randconfig-003-20250123 clang-20 arm64 randconfig-004-20250123 clang-16 loongarch allmodconfig gcc-14.2.0 loongarch allnoconfig gcc-14.2.0 loongarch randconfig-001-20250123 gcc-14.2.0 loongarch randconfig-002-20250123 gcc-14.2.0 x86_64 allnoconfig clang-19 x86_64 allyesconfig clang-19 x86_64 buildonly-randconfig-001-20250123 clang-19 x86_64 buildonly-randconfig-002-20250123 clang-19 x86_64 buildonly-randconfig-003-20250123 gcc-12 x86_64 buildonly-randconfig-004-20250123 gcc-12 x86_64 buildonly-randconfig-005-20250123 clang-19 x86_64 buildonly-randconfig-006-20250123 clang-19 x86_64 defconfig gcc-11 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] zram: fix NULL pointer in comp_algorithm_show()
by Liu Shixin 23 Jan '25

23 Jan '25

mainline inclusion from mainline-v6.13-rc1 commit f364cdeb38938f9d03061682b8ff3779dd1730e5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAFU CVE: CVE-2024-53222 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- LTP reported a NULL pointer dereference as followed: CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_strcmp+0x24/0x140 lr : zcomp_available_show+0x60/0x100 [zram] sp : ffff800088b93b90 x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0 x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280 x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000 Call trace: __pi_strcmp+0x24/0x140 comp_algorithm_show+0x40/0x70 [zram] dev_attr_show+0x28/0x80 sysfs_kf_seq_show+0x90/0x140 kernfs_seq_show+0x34/0x48 seq_read_iter+0x1d4/0x4e8 kernfs_fop_read_iter+0x40/0x58 new_sync_read+0x9c/0x168 vfs_read+0x1a8/0x1f8 ksys_read+0x74/0x108 __arm64_sys_read+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x38/0x138 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190 The zram->comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if comp_algorithm_set() has not been called. User can access the zram device by sysfs after device_add_disk(), so there is a time window to trigger the NULL pointer dereference. Move it ahead device_add_disk() to make sure when user can access the zram device, it is ready. comp_algorithm_set() is protected by zram->init_lock in other places and no such problem. Link: https://lkml.kernel.org/r/20241108100147.3776123-1-liushixin2@huawei.com Fixes: 7ac07a26dea7 ("zram: preparation for multi-zcomp support") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Minchan Kim <minchan(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: drivers/block/zram/zram_drv.c [ Context conflict. ] Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- drivers/block/zram/zram_drv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 8b1ef1dc7162..bb20a8be49a9 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -2404,6 +2404,7 @@ static int zram_add(void) zram->disk->queue = queue; zram->disk->private_data = zram; snprintf(zram->disk->disk_name, 16, "zram%d", device_id); + comp_algorithm_set(zram, ZRAM_PRIMARY_COMP, default_compressor); /* Actual capacity set using syfs (/sys/block/zram<id>/disksize */ set_capacity(zram->disk, 0); @@ -2438,8 +2439,6 @@ static int zram_add(void) blk_queue_flag_set(QUEUE_FLAG_STABLE_WRITES, zram->disk->queue); device_add_disk(NULL, zram->disk, zram_disk_attr_groups); - comp_algorithm_set(zram, ZRAM_PRIMARY_COMP, default_compressor); - zram_debugfs_register(zram); pr_info("Added device: %s\n", zram->disk->disk_name); return device_id; -- 2.34.1

2 1

[PATCH OLK-6.6] mm: khugepaged: fix call hpage_collapse_scan_file() for anonymous vma
by Liu Shixin 23 Jan '25

23 Jan '25

mainline inclusion from mainline-v6.13 commit f1897f2f08b28ae59476d8b73374b08f856973af category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBHBSQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzkaller reported such a BUG_ON(): ------------[ cut here ]------------ kernel BUG at mm/khugepaged.c:1835! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP ... CPU: 6 UID: 0 PID: 8009 Comm: syz.15.106 Kdump: loaded Tainted: G W 6.13.0-rc6 #22 Tainted: [W]=WARN Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : collapse_file+0xa44/0x1400 lr : collapse_file+0x88/0x1400 sp : ffff80008afe3a60 ... Call trace: collapse_file+0xa44/0x1400 (P) hpage_collapse_scan_file+0x278/0x400 madvise_collapse+0x1bc/0x678 madvise_vma_behavior+0x32c/0x448 madvise_walk_vmas.constprop.0+0xbc/0x140 do_madvise.part.0+0xdc/0x2c8 __arm64_sys_madvise+0x68/0x88 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 This indicates that the pgoff is unaligned. After analysis, I confirm the vma is mapped to /dev/zero. Such a vma certainly has vm_file, but it is set to anonymous by mmap_zero(). So even if it's mmapped by 2m-unaligned, it can pass the check in thp_vma_allowable_order() as it is an anonymous-mmap, but then be collapsed as a file-mmap. It seems the problem has existed for a long time, but actually, since we have khugepaged_max_ptes_none check before, we will skip collapse it as it is /dev/zero and so has no present page. But commit d8ea7cc8547c limit the check for only khugepaged, so the BUG_ON() can be triggered by madvise_collapse(). Add vma_is_anonymous() check to make such vma be processed by hpage_collapse_scan_pmd(). Link: https://lkml.kernel.org/r/20250111034511.2223353-1-liushixin2@huawei.com Fixes: d8ea7cc8547c ("mm/khugepaged: add flag to predicate khugepaged-only behavior") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Reviewed-by: Yang Shi <yang(a)os.amperecomputing.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Chengming Zhou <chengming.zhou(a)linux.dev> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Mattew Wilcox <willy(a)infradead.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Qi Zheng <zhengqi.arch(a)bytedance.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/khugepaged.c [ Context conflict with commit 63f118f35263. ] Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/khugepaged.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 7f87636c530e..f8eb225a89f9 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -2426,7 +2426,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result, VM_BUG_ON(khugepaged_scan.address < hstart || khugepaged_scan.address + HPAGE_PMD_SIZE > hend); - if (IS_ENABLED(CONFIG_SHMEM) && vma->vm_file) { + if (IS_ENABLED(CONFIG_SHMEM) && !vma_is_anonymous(vma)) { struct file *file = get_file(vma->vm_file); pgoff_t pgoff = linear_page_index(vma, khugepaged_scan.address); @@ -2776,7 +2776,7 @@ int madvise_collapse(struct vm_area_struct *vma, struct vm_area_struct **prev, memset(cc->node_load, 0, sizeof(cc->node_load)); nodes_clear(cc->alloc_nmask); cc->reliable = false; - if (IS_ENABLED(CONFIG_SHMEM) && vma->vm_file) { + if (IS_ENABLED(CONFIG_SHMEM) && !vma_is_anonymous(vma)) { struct file *file = get_file(vma->vm_file); pgoff_t pgoff = linear_page_index(vma, addr); -- 2.34.1

2 1

[PATCH OLK-6.6] drm/mediatek: Set private->all_drm_private[i]->drm to NULL if mtk_drm_bind returns err
by Ye Bin 23 Jan '25

23 Jan '25

From: Guoqing Jiang <guoqing.jiang(a)canonical.com> stable inclusion from stable-v6.6.72 commit 7083b93e9755d60f0c2bcaa9d064308108280534 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBIQXB CVE: CVE-2024-57926 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 36684e9d88a2e2401ae26715a2e217cb4295cea7 ] The pointer need to be set to NULL, otherwise KASAN complains about use-after-free. Because in mtk_drm_bind, all private's drm are set as follows. private->all_drm_private[i]->drm = drm; And drm will be released by drm_dev_put in case mtk_drm_kms_init returns failure. However, the shutdown path still accesses the previous allocated memory in drm_atomic_helper_shutdown. [ 84.874820] watchdog: watchdog0: watchdog did not stop! [ 86.512054] ================================================================== [ 86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378 [ 86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1 [ 86.515213] [ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55 [ 86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022 [ 86.517960] Call trace: [ 86.518333] show_stack+0x20/0x38 (C) [ 86.518891] dump_stack_lvl+0x90/0xd0 [ 86.519443] print_report+0xf8/0x5b0 [ 86.519985] kasan_report+0xb4/0x100 [ 86.520526] __asan_report_load8_noabort+0x20/0x30 [ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378 [ 86.521966] mtk_drm_shutdown+0x54/0x80 [ 86.522546] platform_shutdown+0x64/0x90 [ 86.523137] device_shutdown+0x260/0x5b8 [ 86.523728] kernel_restart+0x78/0xf0 [ 86.524282] __do_sys_reboot+0x258/0x2f0 [ 86.524871] __arm64_sys_reboot+0x90/0xd8 [ 86.525473] invoke_syscall+0x74/0x268 [ 86.526041] el0_svc_common.constprop.0+0xb0/0x240 [ 86.526751] do_el0_svc+0x4c/0x70 [ 86.527251] el0_svc+0x4c/0xc0 [ 86.527719] el0t_64_sync_handler+0x144/0x168 [ 86.528367] el0t_64_sync+0x198/0x1a0 [ 86.528920] [ 86.529157] The buggy address belongs to the physical page: [ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc [ 86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff) [ 86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000 [ 86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000 [ 86.534511] page dumped because: kasan: bad access detected [ 86.535323] [ 86.535559] Memory state around the buggy address: [ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.544733] ^ [ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.563928] ================================================================== [ 86.571093] Disabling lock debugging due to kernel taint [ 86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b [ 86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f] ... Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Signed-off-by: Guoqing Jiang <guoqing.jiang(a)canonical.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20241223023227.1258112… Signed-off-by: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index ffe016d6cbcf..e192dd1310a7 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -631,6 +631,8 @@ static int mtk_drm_bind(struct device *dev) err_free: private->drm = NULL; drm_dev_put(drm); + for (i = 0; i < private->data->mmsys_dev_num; i++) + private->all_drm_private[i]->drm = NULL; return ret; } -- 2.34.1

2 1

[PATCH OLK-6.6 0/5] Mainline patch to olk-6.6
by Junxian Huang 23 Jan '25

23 Jan '25

From: Xinghai Cen <cenxinghai(a)h-partners.com> Mainline patch to olk-6.6: Chengchang Tang (1): RDMA/hns: Fix UAF for cq async event Junxian Huang (1): RDMA/hns: Check atomic wr length Xinghai Cen (3): Revert "RDMA/hns: Check atomic wr length" Revert "RDMA/hns: Fix a missing check of atomic wr length" Revert "RDMA/hns: Fix UAF for cq async event" drivers/infiniband/hw/hns/hns_roce_cq.c | 3 +-- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 19 +++++-------------- 2 files changed, 6 insertions(+), 16 deletions(-) -- 2.33.0

2 6

[PATCH OLK-6.6] lib/buildid: Handle memfd_secret() files in build_id_parse()
by Tong Tiangen 23 Jan '25

23 Jan '25

From: Andrii Nakryiko <andrii(a)kernel.org> mainline inclusion from mainline-v6.12-rc4 commit 5ac9b4e935dfc6af41eee2ddc21deb5c36507a9f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBJ8HQ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- >From memfd_secret(2) manpage: The memory areas backing the file created with memfd_secret(2) are visible only to the processes that have access to the file descriptor. The memory region is removed from the kernel page tables and only the page tables of the processes holding the file descriptor map the corresponding physical memory. (Thus, the pages in the region can't be accessed by the kernel itself, so that, for example, pointers to the region can't be passed to system calls.) We need to handle this special case gracefully in build ID fetching code. Return -EFAULT whenever secretmem file is passed to build_id_parse() family of APIs. Original report and repro can be found in [0]. [0] https://lore.kernel.org/bpf/ZwyG8Uro%2FSyTXAni@ly-workstation/ Fixes: de3ec364c3c3 ("lib/buildid: add single folio-based file reader abstraction") Reported-by: Yi Lai <yi1.lai(a)intel.com> Suggested-by: Shakeel Butt <shakeel.butt(a)linux.dev> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Shakeel Butt <shakeel.butt(a)linux.dev> Link: https://lore.kernel.org/bpf/20241017175431.6183-A-hca@linux.ibm.com Link: https://lore.kernel.org/bpf/20241017174713.2157873-1-andrii@kernel.org Conflicts: lib/buildid.c [Pre-patch de3ec364c3c3 not merge] Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- lib/buildid.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/lib/buildid.c b/lib/buildid.c index 9fc46366597e..8d839ff5548e 100644 --- a/lib/buildid.c +++ b/lib/buildid.c @@ -5,6 +5,7 @@ #include <linux/elf.h> #include <linux/kernel.h> #include <linux/pagemap.h> +#include <linux/secretmem.h> #define BUILD_ID 3 @@ -157,6 +158,10 @@ int build_id_parse(struct vm_area_struct *vma, unsigned char *build_id, if (!vma->vm_file) return -EINVAL; + /* reject secretmem folios created with memfd_secret() */ + if (vma_is_secretmem(vma)) + return -EFAULT; + page = find_get_page(vma->vm_file->f_mapping, 0); if (!page) return -EFAULT; /* page not mapped */ -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 1/2] [Backport] Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
by Lin Ruifeng 23 Jan '25

23 Jan '25

From: Ignat Korchagin <ignat(a)cloudflare.com> stable inclusion from stable-v5.10.231 commit daa13175a6dea312a76099066cb4cbd4fc959a84 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEANO CVE: CVE-2024-56605 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c4f78cdb8e7501e9f92d291a7d956591bf73be9 ] bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code. Signed-off-by: Ignat Korchagin <ignat(a)cloudflare.com> Reviewed-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20241014153808.51894-3-ignat@cloudflare.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- net/bluetooth/l2cap_sock.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c index bcada51cb01e..9f4a4391f6fe 100644 --- a/net/bluetooth/l2cap_sock.c +++ b/net/bluetooth/l2cap_sock.c @@ -1629,6 +1629,7 @@ static struct sock *l2cap_sock_alloc(struct net *net, struct socket *sock, chan = l2cap_chan_create(); if (!chan) { sk_free(sk); + sock->sk = NULL; return NULL; } -- 2.22.0

2 2

[PATCH OLK-5.10] mm/slub: Reduce memory consumption in extreme scenarios
by Kaixiong Yu 23 Jan '25

23 Jan '25

From: Chen Jun <chenjun102(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit 9198ffbd2b494daae3a67cac1d59c3a2754e64cd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBH72Q Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When kmalloc_node() is called without __GFP_THISNODE and the target node lacks sufficient memory, SLUB allocates a folio from a different node other than the requested node, instead of taking a partial slab from it. However, since the allocated folio does not belong to the requested node, on the following allocation it is deactivated and added to the partial slab list of the node it belongs to. This behavior can result in excessive memory usage when the requested node has insufficient memory, as SLUB will repeatedly allocate folios from other nodes without reusing the previously allocated ones. To prevent memory wastage, when a preferred node is indicated (not NUMA_NO_NODE) but without a prior __GFP_THISNODE constraint: 1) try to get a partial slab from target node only by having __GFP_THISNODE in pc.flags for get_partial() 2) if 1) failed, try to allocate a new slab from target node with GFP_NOWAIT | __GFP_THISNODE opportunistically. 3) if 2) failed, retry with original gfpflags which will allow get_partial() try partial lists of other nodes before potentially allocating new page from other nodes Without a preferred node, or with __GFP_THISNODE constraint, the behavior remains unchanged. On qemu with 4 numa nodes and each numa has 1G memory. Write a test ko to call kmalloc_node(196, GFP_KERNEL, 3) for (4 * 1024 + 4) * 1024 times. cat /proc/slabinfo shows: kmalloc-256 4200530 13519712 256 32 2 : tunables.. after this patch, cat /proc/slabinfo shows: kmalloc-256 4200558 4200768 256 32 2 : tunables.. Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Conflicts: mm/slub.c [The conflict is large. Because OLK-5.10 does not merge mainline patch 53a0de06e50acb372c75d87fcc72ddfdf4a060ee ("mm, slub: dissolve new_slab_objects() into ___slab_alloc()")] Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- mm/slub.c | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 9dd4cc478ec3..d4e7e88df7ff 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2105,7 +2105,7 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node, searchnode = numa_mem_id(); object = get_partial_node(s, get_node(s, searchnode), c, flags); - if (object || node != NUMA_NO_NODE) + if (object || (node != NUMA_NO_NODE && (flags & __GFP_THISNODE))) return object; return get_any_partial(s, flags, c); @@ -2687,6 +2687,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, { void *freelist; struct page *page; + bool try_thisnode = true; + gfp_t pc_gfpflags; stat(s, ALLOC_SLOWPATH); @@ -2764,9 +2766,33 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, goto redo; } - freelist = new_slab_objects(s, gfpflags, node, &c); +new_objects: + + pc_gfpflags = gfpflags; + /* + * When a preferred node is indicated but no __GFP_THISNODE + * + * 1) try to get a partial slab from target node only by having + * __GFP_THISNODE in pc_gfpflags for new_slab_objects() + * 2) if 1) failed, try to allocate a new slab from target node with + * GPF_NOWAIT | __GFP_THISNODE opportunistically + * 3) if 2) failed, retry with original gfpflags which will allow + * new_slab_objects() try partial lists of other nodes before potentially + * allocating new page from other nodes + */ + if (unlikely(node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode)) + pc_gfpflags = GFP_NOWAIT | __GFP_THISNODE; + + freelist = new_slab_objects(s, pc_gfpflags, node, &c); if (unlikely(!freelist)) { + if (node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode) { + try_thisnode = false; + goto new_objects; + } + slab_out_of_memory(s, gfpflags, node); return NULL; } -- 2.34.1

2 1

[PATCH OLK-6.6 0/4] swiotlb: fix swiotlb_bounce() to do partial sync's correctly
by Kaixiong Yu 23 Jan '25

23 Jan '25

task:merge mainline patches into OLK-6.6 Michael Kelley (3): swiotlb: fix swiotlb_bounce() to do partial sync's correctly swiotlb: remove alloc_size argument to swiotlb_tbl_map_single() iommu/dma: fix zeroing of bounce buffer padding used by untrusted devices Petr Tesarik (1): swiotlb: extend buffer pre-padding to alloc_align_mask if necessary drivers/iommu/dma-iommu.c | 31 +++++---- drivers/xen/swiotlb-xen.c | 2 +- include/linux/iova.h | 5 ++ include/linux/swiotlb.h | 2 +- kernel/dma/swiotlb.c | 143 ++++++++++++++++++++++++++------------ 5 files changed, 124 insertions(+), 59 deletions(-) -- 2.34.1

2 5