May 2024 - Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP2] hwmon: (coretemp) Fix out-of-bounds memory access
by Guo Mengqi 20 May '24

20 May '24

From: Zhang Rui <rui.zhang(a)intel.com> stable inclusion from stable-v5.10.210 commit f0da068c75c20ffc5ba28243ff577531dc2af1fd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9DNHE Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4e440abc894585a34c2904a32cd54af1742311b3 ] Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package. Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value") Signed-off-by: Zhang Rui <rui.zhang(a)intel.com> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20240202092144.71180-2-rui.zhang@intel.com Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Stable-dep-of: fdaf0c8629d4 ("hwmon: (coretemp) Fix bogus core_id to attr name mapping") Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/hwmon/coretemp.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c index eaae5de2ab61..f2d1e84600c7 100644 --- a/drivers/hwmon/coretemp.c +++ b/drivers/hwmon/coretemp.c @@ -467,18 +467,14 @@ static int create_core_data(struct platform_device *pdev, unsigned int cpu, if (pkg_flag) { attr_no = PKG_SYSFS_ATTR_NO; } else { - index = ida_alloc(&pdata->ida, GFP_KERNEL); + index = ida_alloc_max(&pdata->ida, NUM_REAL_CORES - 1, GFP_KERNEL); if (index < 0) return index; + pdata->cpu_map[index] = topology_core_id(cpu); attr_no = index + BASE_SYSFS_ATTR_NO; } - if (attr_no > MAX_CORE_DATA - 1) { - err = -ERANGE; - goto ida_free; - } - tdata = init_temp_data(cpu, pkg_flag); if (!tdata) { err = -ENOMEM; -- 2.17.1

2 1

[PATCH OLK-5.10] hwmon: (coretemp) Fix out-of-bounds memory access
by Guo Mengqi 20 May '24

20 May '24

From: Zhang Rui <rui.zhang(a)intel.com> stable inclusion from stable-v5.10.210 commit f0da068c75c20ffc5ba28243ff577531dc2af1fd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9DNHE Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4e440abc894585a34c2904a32cd54af1742311b3 ] Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package. Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value") Signed-off-by: Zhang Rui <rui.zhang(a)intel.com> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20240202092144.71180-2-rui.zhang@intel.com Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Stable-dep-of: fdaf0c8629d4 ("hwmon: (coretemp) Fix bogus core_id to attr name mapping") Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/hwmon/coretemp.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c index 5b2057ce5a59..7f6615ef8c88 100644 --- a/drivers/hwmon/coretemp.c +++ b/drivers/hwmon/coretemp.c @@ -467,18 +467,14 @@ static int create_core_data(struct platform_device *pdev, unsigned int cpu, if (pkg_flag) { attr_no = PKG_SYSFS_ATTR_NO; } else { - index = ida_alloc(&pdata->ida, GFP_KERNEL); + index = ida_alloc_max(&pdata->ida, NUM_REAL_CORES - 1, GFP_KERNEL); if (index < 0) return index; + pdata->cpu_map[index] = topology_core_id(cpu); attr_no = index + BASE_SYSFS_ATTR_NO; } - if (attr_no > MAX_CORE_DATA - 1) { - err = -ERANGE; - goto ida_free; - } - tdata = init_temp_data(cpu, pkg_flag); if (!tdata) { err = -ENOMEM; -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS] gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully
by Guo Mengqi 20 May '24

20 May '24

From: Meng Li <Meng.Li(a)windriver.com> stable inclusion from stable-v5.10.146 commit 657803b918e097e47d99d1489da83a603c36bcdd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9KHLI Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 69bef19d6b9700e96285f4b4e28691cda3dcd0d1 upstream. When running gpio test on nxp-ls1028 platform with below command gpiomon --num-events=3 --rising-edge gpiochip1 25 There will be a warning trace as below: Call trace: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... el0t_64_sync+0x1a0/0x1a4 The reason of this issue is that calling request_threaded_irq() function failed, and then lineevent_free() is invoked to release the resource. Since the lineevent_state::irq was already set, so the subsequent invocation of free_irq() would trigger the above warning call trace. To fix this issue, set the lineevent_state::irq after the IRQ register successfully. Fixes: 468242724143 ("gpiolib: cdev: refactor lineevent cleanup into lineevent_free") Cc: stable(a)vger.kernel.org Signed-off-by: Meng Li <Meng.Li(a)windriver.com> Reviewed-by: Kent Gibson <warthog618(a)gmail.com> Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/gpio/gpiolib-cdev.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c index 2613881a66e6..381cfa26a4a1 100644 --- a/drivers/gpio/gpiolib-cdev.c +++ b/drivers/gpio/gpiolib-cdev.c @@ -1769,7 +1769,6 @@ static int lineevent_create(struct gpio_device *gdev, void __user *ip) ret = -ENODEV; goto out_free_le; } - le->irq = irq; if (eflags & GPIOEVENT_REQUEST_RISING_EDGE) irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ? @@ -1783,7 +1782,7 @@ static int lineevent_create(struct gpio_device *gdev, void __user *ip) init_waitqueue_head(&le->wait); /* Request a thread to read the events */ - ret = request_threaded_irq(le->irq, + ret = request_threaded_irq(irq, lineevent_irq_handler, lineevent_irq_thread, irqflags, @@ -1792,6 +1791,8 @@ static int lineevent_create(struct gpio_device *gdev, void __user *ip) if (ret) goto out_free_le; + le->irq = irq; + fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC); if (fd < 0) { ret = fd; -- 2.17.1

2 1

[PATCH OLK-6.6 0/4] LoongArch: fix kdump not work when legacy mode disabled
by Hongchen Zhang 20 May '24

20 May '24

Hongchen Zhang (4): Revert "LoongArch: kdump: Add high memory reservation" Revert "LoongArch: Fix kdump failure on v40 interface specification" Revert "LoongArch: kdump: Add memory reservation for old kernel" LoongArch: fix efi map page table error arch/loongarch/kernel/efi.c | 39 ++++++++++++--- arch/loongarch/kernel/setup.c | 94 +++++------------------------------ 2 files changed, 44 insertions(+), 89 deletions(-) -- 2.33.0

2 5

[PATCH OLK-5.10 0/3] adjusting the interface to adapt to the cca community
by Ju Fu 20 May '24

20 May '24

adjusting the interface to adapt to the cca community: cvm: enable secure memory alloc on multiple numa nodes cvm: support observable usage of secure memory cvm: adjusting the interface to adapt to the cca community arch/arm64/include/asm/kvm_pgtable.h | 3 + arch/arm64/include/asm/kvm_tmi.h | 40 +- arch/arm64/include/asm/kvm_tmm.h | 1 - arch/arm64/include/asm/sysreg.h | 3 + arch/arm64/include/uapi/asm/kvm.h | 4 + arch/arm64/kvm/arm.c | 13 +- arch/arm64/kvm/cvm.c | 412 ++++++++++++-------- arch/arm64/kvm/reset.c | 6 + arch/arm64/kvm/tmi.c | 23 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 + include/uapi/linux/kvm.h | 3 +- 11 files changed, 320 insertions(+), 191 deletions(-) -- 2.25.1.windows.1

2 4

[PATCH OLK-5.10] btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
by Yifan Qiao 20 May '24

20 May '24

From: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> stable inclusion from stable-v4.19.313 commit 689efe22e9b5b7d9d523119a9a5c3c17107a0772 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9HO CVE: CVE-2024-35849 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf upstream. Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000 This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory. Fix this by using kvzalloc() which zeroes out the memory on allocation. CC: stable(a)vger.kernel.org # 4.14+ Reported-by: <syzbot+510a1abbb8116eeb341d(a)syzkaller.appspotmail.com> Reviewed-by: Qu Wenruo <wqu(a)suse.com> Reviewed-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: Johannes Thumshirn <Johannes.thumshirn(a)wdc.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/btrfs/backref.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c index d2f77b1242a1..f1731eeb86a7 100644 --- a/fs/btrfs/backref.c +++ b/fs/btrfs/backref.c @@ -2315,20 +2315,14 @@ struct btrfs_data_container *init_data_container(u32 total_bytes) size_t alloc_bytes; alloc_bytes = max_t(size_t, total_bytes, sizeof(*data)); - data = kvmalloc(alloc_bytes, GFP_KERNEL); + data = kvzalloc(alloc_bytes, GFP_KERNEL); if (!data) return ERR_PTR(-ENOMEM); - if (total_bytes >= sizeof(*data)) { + if (total_bytes >= sizeof(*data)) data->bytes_left = total_bytes - sizeof(*data); - data->bytes_missing = 0; - } else { + else data->bytes_missing = sizeof(*data) - total_bytes; - data->bytes_left = 0; - } - - data->elem_cnt = 0; - data->elem_missed = 0; return data; } -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
by Yifan Qiao 20 May '24

20 May '24

From: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> stable inclusion from stable-v4.19.313 commit 689efe22e9b5b7d9d523119a9a5c3c17107a0772 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9HO CVE: CVE-2024-35849 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf upstream. Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000 This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory. Fix this by using kvzalloc() which zeroes out the memory on allocation. CC: stable(a)vger.kernel.org # 4.14+ Reported-by: <syzbot+510a1abbb8116eeb341d(a)syzkaller.appspotmail.com> Reviewed-by: Qu Wenruo <wqu(a)suse.com> Reviewed-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: Johannes Thumshirn <Johannes.thumshirn(a)wdc.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/btrfs/backref.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c index 19855659f650..280601bf7e02 100644 --- a/fs/btrfs/backref.c +++ b/fs/btrfs/backref.c @@ -2208,20 +2208,14 @@ struct btrfs_data_container *init_data_container(u32 total_bytes) size_t alloc_bytes; alloc_bytes = max_t(size_t, total_bytes, sizeof(*data)); - data = kvmalloc(alloc_bytes, GFP_KERNEL); + data = kvzalloc(alloc_bytes, GFP_KERNEL); if (!data) return ERR_PTR(-ENOMEM); - if (total_bytes >= sizeof(*data)) { + if (total_bytes >= sizeof(*data)) data->bytes_left = total_bytes - sizeof(*data); - data->bytes_missing = 0; - } else { + else data->bytes_missing = sizeof(*data) - total_bytes; - data->bytes_left = 0; - } - - data->elem_cnt = 0; - data->elem_missed = 0; return data; } -- 2.39.2

2 1

[PATCH OLK-5.10 00/11] sync hulk-5.10 patches
by Yu Kuai 20 May '24

20 May '24

Three features related: - add a switch to enable hungtask check for io, patch 1-2 - add a config to control hierarchical throttle, patch 3-4 - support enable/disable blk-mq debugfs dynamically, patch 5-11 Christoph Hellwig (2): block: serialize all debugfs operations using q->debugfs_mutex block: remove per-disk debugfs files in blk_unregister_queue Yu Kuai (9): block: add a switch to enable hungtask check for io block: disable BLK_IO_HUNG_TASK_CHECK by default blk-throttle: add a config to control hierarchical throttle in cgroup v1 blk-throttle: fix missing prefix "CONFIG_" block: protect blk_mq_debugfs_register/unregister_hctx() with 'debugfs_mutex' block: shutdown blktrace in blk_release_queue() block: support enable/disable blk-mq debugfs dynamically block: fix kabi broken in struct request_queue block: support to disable debugfs by default arch/arm64/configs/openeuler_defconfig | 2 + arch/x86/configs/openeuler_defconfig | 2 + block/Kconfig | 31 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 +++- block/blk-exec.c | 2 +- block/blk-mq-debugfs.c | 87 ++++++++++++++++++++++---- block/blk-mq-debugfs.h | 5 -- block/blk-mq-sched.c | 11 ++++ block/blk-mq.c | 12 ++++ block/blk-rq-qos.c | 2 - block/blk-rq-qos.h | 7 ++- block/blk-sysfs.c | 82 ++++++++++++++++++++---- block/blk-throttle.c | 17 ++++- block/blk.h | 1 + include/linux/blkdev.h | 8 ++- kernel/trace/blktrace.c | 3 - 17 files changed, 245 insertions(+), 42 deletions(-) -- 2.39.2

2 12

[PATCH OLK-5.10 v2] rcu: shorten the critical section that rnp->lock protects in rcu_dump_cpu_stacks
by Wei Li 20 May '24

20 May '24

From: Zheng Zengkai <zhengzengkai(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7MQJB -------------------------------- Concurrent ltp stress testcases cause a hardlockup issue in KunPeng920: ------------[ cut here ]------------ [ 2301.316914] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 2301.320386] try_charge+0x2c8/0x600 [ 2301.325566] rcu: 69-...0: (23 ticks this GP) idle=fb2/1/0x4000000000000000 softirq=39368/39368 fqs=5591 [ 2301.335766] (detected by 29, t=15006 jiffies, g=91585, q=3635521) [ 2301.345458] Sending NMI from CPU 29 to CPUs 69: ------------[ cut here ]------------ [ 2379.033470] NMI watchdog: Watchdog detected hard LOCKUP on cpu 69 [ 2379.033523] CPU: 69 PID: 2143608 Comm: memcg_test_1 Kdump: loaded Tainted: G W 5.10.0-sp2-lockdepdbg+ #45 [ 2379.033524] Hardware name: Huawei TaiShan 5280 V2/BC82AMDDA, BIOS 1.93 10/13/2022 [ 2379.033525] pstate: 00400089 (nzcv daIf +PAN -UAO -TCO BTYPE=--) [ 2379.033525] pc : native_queued_spin_lock_slowpath+0x264/0x330 [ 2379.033526] lr : rcu_iw_handler+0xc4/0x130 [ 2379.033527] sp : ffff80001022be60 [ 2379.033528] x29: ffff80001022be60 x28: ffff2f6c7cc44d00 [ 2379.033529] x27: ffff2f6b81ee21a8 x26: ffff80001022c000 [ 2379.033530] x25: ffff800010228000 x24: ffffd913b32a6000 [ 2379.033532] x23: 0000000000000000 x22: ffffd913b3aa4000 [ 2379.033533] x21: ffffd913b32ba5f0 x20: ffff2f6b7ffa37c0 [ 2379.033534] x19: ffffd913b365c440 x18: 0000000000000060 [ 2379.033535] x17: 0000000000000000 x16: 0000000000000000 [ 2379.033537] x15: ffffffffffffffff x14: ffff8000bcb9b4f0 [ 2379.033538] x13: 00000000fffffffd x12: 0000000000000040 [ 2379.033539] x11: ffff2f63806bada0 x10: ffff2f63806bada2 [ 2379.033541] x9 : 0000000000000000 x8 : 0000000000000000 [ 2379.033542] x7 : ffff2f6b7ffa3740 x6 : ffffd913b2f67740 [ 2379.033543] x5 : ffff2f6b7ffa3740 x4 : 0000000001180101 [ 2379.033544] x3 : ffffd913b365c440 x2 : 0000000000000118 [ 2379.033545] x1 : 0000000001180000 x0 : 0000000000000000 [ 2379.033547] Call trace: [ 2379.033547] native_queued_spin_lock_slowpath+0x264/0x330 [ 2379.033548] irq_work_single+0x38/0x9c [ 2379.033548] flush_smp_call_function_queue+0x144/0x26c [ 2379.033549] generic_smp_call_function_single_interrupt+0x1c/0x30 [ 2379.033550] do_handle_IPI+0x84/0x2e4 [ 2379.033550] ipi_handler+0x24/0x3c [ 2379.033551] handle_percpu_devid_fasteoi_ipi+0x84/0x14c [ 2379.033552] __handle_domain_irq+0x84/0xf0 [ 2379.033553] gic_handle_irq+0x78/0x2c0 [ 2379.033553] el1_irq+0xb8/0x140 [ 2379.033554] dump_stack+0xe8/0x140 [ 2379.033554] dump_header+0x50/0x19c [ 2379.033555] out_of_memory+0x338/0x380 [ 2379.033556] mem_cgroup_out_of_memory+0x128/0x144 [ 2379.033557] mem_cgroup_oom+0x188/0x250 [ 2379.033557] try_charge+0x2c8/0x600 [ 2379.033558] mem_cgroup_charge+0x128/0x424 [ 2379.033559] wp_page_copy+0xc8/0xb40 [ 2379.033559] do_wp_page+0x228/0x594 [ 2379.033560] handle_pte_fault+0x1f8/0x21c [ 2379.033561] __handle_mm_fault+0x1b0/0x380 [ 2379.033561] handle_mm_fault+0xf4/0x250 [ 2379.033562] do_page_fault+0x188/0x454 [ 2379.033563] do_mem_abort+0x48/0xb0 [ 2379.033563] el0_da+0x44/0x80 [ 2379.033564] el0_sync_handler+0x88/0xb4 [ 2379.033564] el0_sync+0x160/0x180 cpu29 cpu69 rcu_dump_cpu_stacks() grab rnp->lock nmi_trigger_cpumask_backtrace() arm64_send_ipi() do_handle_IPI flush_smp_call_function_queue rcu_iw_handler spin rnp->lock deadlock nmi_cpu_backtrace wait for 10s or backtrace_mask clear For arm64 w/o NMI-triggered stack traces, IPI backtrace feature is used, while in rcu_dump_cpu_stacks(), raw_spin_lock_irqsave_rcu_node() will grab the rcu_node->lock to protect the rcu_node data used in the for_each_leaf_node_possible_cpu loop, while the process of backtrace for the rcu stalled cpu may be longer than expected, causing potential concurrent issue while someone contending for the same rcu_node->lock. Like the call trace shown above, rcu_node->lock will not be released until all the stalled cpus' backtrace finished in nmi_cpu_backtrace() or 10s timeout in nmi_trigger_cpumask_backtrace(), if there are pending IPI callbacks in the smp call_single_queue ahead of the ipi_cpu_backtrace callback contending for the same rcu_node->lock, deadlock will be inevitable. To avoid such problems, shorten the critical section that rcu_node->lock protects to avoid waiting for the backtrace process finish. Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Fixes: 81ad62c3883e ("arm64: Fix the ipi backtrace warning when softlockup") Signed-off-by: Wei Li <liwei391(a)huawei.com> --- kernel/rcu/tree_stall.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h index e9d8b6dbde7c..35624190c6f2 100644 --- a/kernel/rcu/tree_stall.h +++ b/kernel/rcu/tree_stall.h @@ -334,10 +334,12 @@ static void rcu_dump_cpu_stacks(void) raw_spin_lock_irqsave_rcu_node(rnp, flags); for_each_leaf_node_possible_cpu(rnp, cpu) if (rnp->qsmask & leaf_node_cpu_bit(rnp, cpu)) { + raw_spin_unlock_irqrestore_rcu_node(rnp, flags); if (cpu_is_offline(cpu)) pr_err("Offline CPU %d blocking current GP.\n", cpu); else dump_cpu_task(cpu); + raw_spin_lock_irqsave_rcu_node(rnp, flags); } raw_spin_unlock_irqrestore_rcu_node(rnp, flags); } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 v2 0/7] CVE-2024-26907
by Ziyang Xuan 20 May '24

20 May '24

Patchset of CVE-2024-26907. v2: - Add new bugfix. Alexey Dobriyan (1): uapi: stddef.h: Fix __DECLARE_FLEX_ARRAY for C++ Dmitry Antipov (1): uapi: propagate __struct_group() attributes to the container union Kees Cook (3): stddef: Introduce struct_group() helper macro stddef: Introduce DECLARE_FLEX_ARRAY() helper kernel-doc: fix struct_group_tagged() parsing Leon Romanovsky (1): RDMA/mlx5: Fix fortify source warning while accessing Eth segment Tadeusz Struk (1): uapi/linux/stddef.h: Add include guards drivers/infiniband/hw/mlx5/wr.c | 2 +- include/linux/mlx5/qp.h | 5 ++- include/linux/stddef.h | 61 +++++++++++++++++++++++++++++++++ include/uapi/linux/stddef.h | 48 ++++++++++++++++++++++++++ scripts/kernel-doc | 11 +++++- 5 files changed, 124 insertions(+), 3 deletions(-) -- 2.25.1

2 8

2024

2023

2022

2021

2020

2019

Kernel May 2024