July 2024 - Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH v2 OLK-6.6] Revert "ACPI: processor: Add support for processors described as container packages"
by liwei 04 Jul '24

04 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAJ94 ---------------------------- 'processor_container_handler' identifies ACPI0010 does not match the Processor information reported by DSDT. This reverts commit 2f257a8ec840ccc5fcefab424f468552da7b15ff. Fixes: 2f257a8ec840 ("ACPI: processor: Add support for processors described as container packages") Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/acpi/acpi_processor.c | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 0ff69af46a50..d46e1fe25d58 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -698,31 +698,9 @@ static struct acpi_scan_handler processor_handler = { }, }; -static acpi_status acpi_processor_container_walk(acpi_handle handle, - u32 lvl, - void *context, - void **rv) -{ - struct acpi_device *adev; - acpi_status status; - - adev = acpi_get_acpi_dev(handle); - if (!adev) - return AE_ERROR; - - status = acpi_processor_add(adev, &processor_device_ids[0]); - acpi_put_acpi_dev(adev); - - return status; -} - static int acpi_processor_container_attach(struct acpi_device *dev, const struct acpi_device_id *id) { - acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle, - ACPI_UINT32_MAX, acpi_processor_container_walk, - NULL, NULL, NULL); - return 1; } -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2024-36949
by Zheng Zucheng 04 Jul '24

04 Jul '24

Mukul Joshi (1): drm/amdkfd: Rework kfd_locked handling Zhigang Luo (1): amd/amdkfd: sync all devices to wait all processes being evicted drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 3 --- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 27 +++++++++++++++--------- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 + drivers/gpu/drm/amd/amdkfd/kfd_process.c | 8 ++++++- 4 files changed, 25 insertions(+), 14 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS V1] USB: core: Fix hang in usb_kill_urb by adding memory barriers
by Cheng Yu 04 Jul '24

04 Jul '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v5.10.96 commit e3b131e30e612ff0e32de6c1cb4f69f89db29193 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72HV CVE: CVE-2022-48760 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 26fbe9772b8c459687930511444ce443011f86bf upstream. The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers. CC: <stable(a)vger.kernel.org> Reported-and-tested-by: syzbot+76629376e06e2c2ad626(a)syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/usb/core/hcd.c | 14 ++++++++++++++ drivers/usb/core/urb.c | 12 ++++++++++++ 2 files changed, 26 insertions(+) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 62e6c526e6ed..acff95a9f239 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1663,6 +1663,13 @@ int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags) urb->hcpriv = NULL; INIT_LIST_HEAD(&urb->urb_list); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + atomic_dec(&urb->dev->urbnum); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); @@ -1772,6 +1779,13 @@ static void __usb_hcd_giveback_urb(struct urb *urb) usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + if (unlikely(atomic_read(&urb->reject))) wake_up(&usb_kill_urb_queue); usb_put_urb(urb); diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c index 5e844097a9e3..abf4681159df 100644 --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -692,6 +692,12 @@ void usb_kill_urb(struct urb *urb) if (!(urb && urb->dev && urb->ep)) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); usb_hcd_unlink_urb(urb, -ENOENT); wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); @@ -733,6 +739,12 @@ void usb_poison_urb(struct urb *urb) if (!urb) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); if (!urb->dev || !urb->ep) return; -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 23159/23203] include/asm-generic/atomic-instrumented.h:33:9: warning: 'wait_req' may be used uninitialized
by kernel test robot 04 Jul '24

04 Jul '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 3747e12f550e11fcfb6878af5c6e88f3e4af0d1f commit: 6741506ca02825b90e77088e8fce01c3d02edfdd [23159/23203] nilfs2: fix unexpected freezing of nilfs_segctor_sync() config: x86_64-buildonly-randconfig-005-20240704 (https://download.01.org/0day-ci/archive/20240704/202407041352.YmlrzTKf-lkp@…) compiler: gcc-12 (Ubuntu 12.3.0-9ubuntu2) 12.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240704/202407041352.YmlrzTKf-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/202407041352.YmlrzTKf-lkp@intel.com/ Note: it may well be a FALSE warning. FWIW you are at least aware of it now. http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings All warnings (new ones prefixed by >>): In file included from arch/x86/include/asm/atomic.h:265, from arch/x86/include/asm/msr.h:67, from arch/x86/include/asm/processor.h:21, from arch/x86/include/asm/cpufeature.h:5, from arch/x86/include/asm/thread_info.h:53, from include/linux/thread_bits.h:22, from include/linux/thread_info.h:14, from arch/x86/include/asm/preempt.h:7, from include/linux/preempt.h:81, from include/linux/spinlock.h:51, from include/linux/mmzone.h:9, from include/linux/gfp.h:6, from include/linux/mm.h:11, from include/linux/pagemap.h:8, from fs/nilfs2/segment.c:11: In function 'atomic_set', inlined from 'nilfs_segctor_sync' at fs/nilfs2/segment.c:2175:2: >> include/asm-generic/atomic-instrumented.h:33:9: warning: 'wait_req' may be used uninitialized [-Wmaybe-uninitialized] 33 | kasan_check_write(v, sizeof(*v)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/compiler.h:265, from include/asm-generic/bug.h:5, from arch/x86/include/asm/bug.h:83, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/mm.h:10: include/linux/kasan-checks.h: In function 'nilfs_segctor_sync': include/linux/kasan-checks.h:7:6: note: by argument 1 of type 'const volatile void *' to 'kasan_check_write' declared here 7 | void kasan_check_write(const volatile void *p, unsigned int size); | ^~~~~~~~~~~~~~~~~ fs/nilfs2/segment.c:2170:43: note: 'wait_req' declared here 2170 | struct nilfs_segctor_wait_request wait_req; | ^~~~~~~~ vim +/wait_req +33 include/asm-generic/atomic-instrumented.h b06ed71a624ba0 Dmitry Vyukov 2018-01-29 30 b06ed71a624ba0 Dmitry Vyukov 2018-01-29 31 static __always_inline void atomic_set(atomic_t *v, int i) b06ed71a624ba0 Dmitry Vyukov 2018-01-29 32 { a35353bb9eb199 Dmitry Vyukov 2018-01-29 @33 kasan_check_write(v, sizeof(*v)); b06ed71a624ba0 Dmitry Vyukov 2018-01-29 34 arch_atomic_set(v, i); b06ed71a624ba0 Dmitry Vyukov 2018-01-29 35 } b06ed71a624ba0 Dmitry Vyukov 2018-01-29 36 :::::: The code at line 33 was first introduced by commit :::::: a35353bb9eb1990a44a0d7585f99e9589bcdb682 locking/atomic, asm-generic: Add KASAN instrumentation to atomic operations :::::: TO: Dmitry Vyukov <dvyukov(a)google.com> :::::: CC: Ingo Molnar <mingo(a)kernel.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] Revert "ACPI: processor: Add support for processors described as container packages"
by liwei 04 Jul '24

04 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAJ94 ---------------------------- 'processor_container_handler' identifies ACPI0010 does not match the Processor information reported by DSDT. This reverts commit 2f257a8ec840ccc5fcefab424f468552da7b15ff. Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/acpi/acpi_processor.c | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 0ff69af46a50..d46e1fe25d58 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -698,31 +698,9 @@ static struct acpi_scan_handler processor_handler = { }, }; -static acpi_status acpi_processor_container_walk(acpi_handle handle, - u32 lvl, - void *context, - void **rv) -{ - struct acpi_device *adev; - acpi_status status; - - adev = acpi_get_acpi_dev(handle); - if (!adev) - return AE_ERROR; - - status = acpi_processor_add(adev, &processor_device_ids[0]); - acpi_put_acpi_dev(adev); - - return status; -} - static int acpi_processor_container_attach(struct acpi_device *dev, const struct acpi_device_id *id) { - acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle, - ACPI_UINT32_MAX, acpi_processor_container_walk, - NULL, NULL, NULL); - return 1; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] scsi: qedf: Ensure the copied buf is NUL terminated
by Zheng Zucheng 04 Jul '24

04 Jul '24

From: Bui Quang Minh <minhquangbui99(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit d0184a375ee797eb657d74861ba0935b6e405c62 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHD CVE: CVE-2024-38559 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Signed-off-by: Bui Quang Minh <minhquangbui99(a)gmail.com> Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-4-f1f1b53a10f4@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/scsi/qedf/qedf_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qedf/qedf_debugfs.c b/drivers/scsi/qedf/qedf_debugfs.c index c29c162a494f..e7a609b5791d 100644 --- a/drivers/scsi/qedf/qedf_debugfs.c +++ b/drivers/scsi/qedf/qedf_debugfs.c @@ -181,7 +181,7 @@ qedf_dbg_debug_cmd_write(struct file *filp, const char __user *buffer, if (!count || *ppos) return 0; - kern_buf = memdup_user(buffer, count); + kern_buf = memdup_user_nul(buffer, count); if (IS_ERR(kern_buf)) return PTR_ERR(kern_buf); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] dma-mapping: benchmark: handle NUMA_NO_NODE correctly
by Liu Shixin 04 Jul '24

04 Jul '24

From: Fedor Pchelkin <pchelkin(a)ispras.ru> mainline inclusion from mainline-v6.10-rc2 commit e64746e74f717961250a155e14c156616fcd981f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DCL CVE: CVE-2024-39277 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan.c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Use cpumask_of_node() in place when binding a kernel thread to a cpuset of a particular node. Note that the provided node id is checked inside map_benchmark_ioctl(). It's just a NUMA_NO_NODE case which is not handled properly later. Found by Linux Verification Center (linuxtesting.org). Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs") Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Acked-by: Barry Song <baohua(a)kernel.org> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- kernel/dma/map_benchmark.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index e0e64f8b0739..c2d225e1cd47 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -121,7 +121,6 @@ static int do_map_benchmark(struct map_benchmark_data *map) struct task_struct **tsk; int threads = map->bparam.threads; int node = map->bparam.node; - const cpumask_t *cpu_mask = cpumask_of_node(node); u64 loops; int ret = 0; int i; @@ -142,7 +141,7 @@ static int do_map_benchmark(struct map_benchmark_data *map) } if (node != NUMA_NO_NODE) - kthread_bind_mask(tsk[i], cpu_mask); + kthread_bind_mask(tsk[i], cpumask_of_node(node)); } /* clear the old value in the previous benchmark */ -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
by Liu Shixin 04 Jul '24

04 Jul '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.219 commit 4b68b861b514a5c09220d622ac3784c0ebac6c80 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGC CVE: CVE-2024-38547 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3b621e9e9e148c0928ab109ac3d4b81487469acb ] The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered. Link: https://lore.kernel.org/r/20240118151303.3828292-1-alexious@zju.edu.cn Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- drivers/staging/media/atomisp/pci/sh_css.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/atomisp/pci/sh_css.c b/drivers/staging/media/atomisp/pci/sh_css.c index 54a18921fbd1..cb0354520360 100644 --- a/drivers/staging/media/atomisp/pci/sh_css.c +++ b/drivers/staging/media/atomisp/pci/sh_css.c @@ -5477,6 +5477,7 @@ static int load_video_binaries(struct ia_css_pipe *pipe) mycs->yuv_scaler_binary = kzalloc(cas_scaler_descr.num_stage * sizeof(struct ia_css_binary), GFP_KERNEL); if (!mycs->yuv_scaler_binary) { + mycs->num_yuv_scaler = 0; err = -ENOMEM; return err; } -- 2.25.1

2 1

2024

2023

2022

2021

2020

2019

Kernel July 2024