April 2024 - Kernel - mailweb.openeuler.org

[PATCH V4 OLK-6.6] mm, fs: Add BPF_READAHEAD_OPTIMIZATION option for bpf readhead
by ZhaoLong Wang 23 Apr '24

23 Apr '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7Y9JD CVE: NA --------------------------- This patch introduces a new configuration option called BPF_READAHEAD, which is designed to optimize the read performance in Spark SQL scenarios using eBPF to implement a programmable kernel. The changes include: - Add CONFIG_BPF_READAHEAD to mm/Kconfig, which depends on CONFIG_TRACEPOINTS. - Add conditional compilation directives to fs/ext4/file.c, fs/read_write.c, fs/xfs/xfs_file.c, and include/linux/fs.h to include tracepoint-related headers and functions only when BPF_READAHEAD is enabled. - Miodify page_cache_sync_ra() in mm/readahead.c to disable forced readahead when BPF_READAHEAD is not enabled. V2: Explicitly set CONFIG_ in openeuler_defconfig. Do not add redundant macros to mm/readahead. V3: Place all macro isolation switches in the .h header file. V4: Change the macro name BPF_READAHEAD_OPTIMIZATION to BPF_READAHEAD Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 1 + arch/powerpc/configs/openeuler_defconfig | 1 + arch/riscv/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + fs/read_write.c | 4 ++-- include/linux/fs.h | 18 +++++++++++++----- include/trace/events/fs.h | 6 ++++++ mm/Kconfig | 9 +++++++++ 8 files changed, 34 insertions(+), 7 deletions(-) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index 9a6ef6175717..b8bdcf53c062 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -1192,6 +1192,7 @@ CONFIG_DYNAMIC_POOL=y CONFIG_ETMEM_SCAN=m CONFIG_ETMEM_SWAP=m CONFIG_ETMEM=y +# CONFIG_BPF_READAHEAD_OPTIMIZATION is not set # # Data Access Monitoring diff --git a/arch/powerpc/configs/openeuler_defconfig b/arch/powerpc/configs/openeuler_defconfig index 152b941da1d5..793cca85862c 100644 --- a/arch/powerpc/configs/openeuler_defconfig +++ b/arch/powerpc/configs/openeuler_defconfig @@ -860,6 +860,7 @@ CONFIG_ARCH_HAS_HUGEPD=y CONFIG_USERFAULTFD=y # CONFIG_LRU_GEN is not set CONFIG_LOCK_MM_AND_FIND_VMA=y +# CONFIG_BPF_READAHEAD_OPTIMIZATION is not set # # Data Access Monitoring diff --git a/arch/riscv/configs/openeuler_defconfig b/arch/riscv/configs/openeuler_defconfig index cb132f4576da..06caed7e855a 100644 --- a/arch/riscv/configs/openeuler_defconfig +++ b/arch/riscv/configs/openeuler_defconfig @@ -825,6 +825,7 @@ CONFIG_ARCH_SUPPORTS_PER_VMA_LOCK=y CONFIG_PER_VMA_LOCK=y CONFIG_LOCK_MM_AND_FIND_VMA=y # CONFIG_PAGE_CACHE_LIMIT is not set +# CONFIG_BPF_READAHEAD_OPTIMIZATION is not set # # Data Access Monitoring diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index 1d20beb4bb6d..3338dc1c7037 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -1179,6 +1179,7 @@ CONFIG_DYNAMIC_POOL=y CONFIG_ETMEM_SCAN=m CONFIG_ETMEM_SWAP=m CONFIG_ETMEM=y +# CONFIG_BPF_READAHEAD_OPTIMIZATION is not set # # Data Access Monitoring diff --git a/fs/read_write.c b/fs/read_write.c index 3d69fb284d10..265e40589be8 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -1721,7 +1721,7 @@ int generic_file_rw_checks(struct file *file_in, struct file *file_out) return 0; } -#ifdef CONFIG_TRACEPOINTS +#ifdef CONFIG_BPF_READAHEAD_OPTIMIZATION static void fs_file_read_ctx_init(struct fs_file_read_ctx *ctx, struct file *filp, loff_t pos) { @@ -1752,7 +1752,7 @@ void fs_file_read_update_args_by_trace(struct kiocb *iocb) filp->f_ctl_mode &= ~(ctx.clr_f_mode & FS_FILE_READ_MODE_MASK); } EXPORT_SYMBOL_GPL(fs_file_read_update_args_by_trace); -#endif EXPORT_TRACEPOINT_SYMBOL_GPL(fs_file_read); EXPORT_TRACEPOINT_SYMBOL_GPL(fs_file_release); +#endif diff --git a/include/linux/fs.h b/include/linux/fs.h index d74314a8fa94..2702d38b57ab 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -43,7 +43,9 @@ #include <linux/cred.h> #include <linux/mnt_idmapping.h> #include <linux/slab.h> +#ifdef CONFIG_BPF_READAHEAD_OPTIMIZATION #include <linux/tracepoint-defs.h> +#endif #include <linux/kabi.h> #include <asm/byteorder.h> @@ -190,11 +192,16 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, /* File supports async nowait buffered writes */ #define FMODE_BUF_WASYNC ((__force fmode_t)0x80000000) +#ifdef CONFIG_BPF_READAHEAD_OPTIMIZATION /* File mode control flag, expect random access pattern */ #define FMODE_CTL_RANDOM ((__force fmode_t)0x1000) /* File mode control flag, will try to read head of the file into pagecache */ #define FMODE_CTL_WILLNEED ((__force fmode_t)0x400000) +#else +#define FMODE_CTL_RANDOM 0 +#define FMODE_CTL_WILLNEED 0 +#endif /* * Attribute flags. These should be or-ed together to figure out what @@ -3524,16 +3531,17 @@ struct fs_file_read_ctx { long long index; }; -#ifdef CONFIG_TRACEPOINTS +#ifdef CONFIG_BPF_READAHEAD_OPTIMIZATION DECLARE_TRACEPOINT(fs_file_read); extern void fs_file_read_update_args_by_trace(struct kiocb *iocb); -#else -static inline void fs_file_read_update_args_by_trace(struct kiocb *iocb) {} -#endif - static inline void fs_file_read_do_trace(struct kiocb *iocb) { if (tracepoint_enabled(fs_file_read)) fs_file_read_update_args_by_trace(iocb); } +#else +static inline void fs_file_read_update_args_by_trace(struct kiocb *iocb) {} +static inline void fs_file_read_do_trace(struct kiocb *iocb) {} +#endif + #endif /* _LINUX_FS_H */ diff --git a/include/trace/events/fs.h b/include/trace/events/fs.h index ee82dad9d9da..e0e595160f44 100644 --- a/include/trace/events/fs.h +++ b/include/trace/events/fs.h @@ -1,4 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ +#ifdef CONFIG_BPF_READAHEAD_OPTIMIZATION + #undef TRACE_SYSTEM #define TRACE_SYSTEM fs @@ -31,3 +33,7 @@ DECLARE_TRACE(fs_file_release, /* This part must be outside protection */ #include <trace/define_trace.h> +#else +#define trace_fs_file_release(...) +#define trace_fs_file_read(...) +#endif /* CONFIG_BPF_READAHEAD_OPTIMIZATION */ diff --git a/mm/Kconfig b/mm/Kconfig index cdbb1ceaa554..45d4139c959c 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1424,6 +1424,15 @@ config ETMEM high-performance storage media to release memory space and reduce memory costs. +config BPF_READAHEAD + bool "Enable bpf readahead optimization" + select TRACEPOINTS + default n + help + EBPF is used to implement a programmable kernel. The readahead behavior + of the kernel is adjusted based on the application read mode to optimize + the read performance in the Spark SQL scenario, + source "mm/damon/Kconfig" endmenu -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS 0/1] CVE-2024-26875
by Zhu Wang 23 Apr '24

23 Apr '24

*** BLURB HERE *** Edward Adam Davis (1): media: pvrusb2: fix uaf in pvr2_context_set_notify drivers/media/usb/pvrusb2/pvrusb2-context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] media: pvrusb2: fix uaf in pvr2_context_set_notify
by Zhu Wang 23 Apr '24

23 Apr '24

From: Edward Adam Davis <eadavis(a)qq.com> mainline inclusion from mainline-v6.9-rc1 commit 0a0b79ea55de8514e1750884e5fec77f9fdd01ee category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK8R CVE: CVE-2024-26875 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272 Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 [Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue. [Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue. Reported-and-tested-by: syzbot+ce750e124675d4599449(a)syzkaller.appspotmail.com Fixes: e5be15c63804 ("V4L/DVB (7711): pvrusb2: Fix race on module unload") Signed-off-by: Edward Adam Davis <eadavis(a)qq.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Zhu Wang <wangzhu9(a)huawei.com> --- drivers/media/usb/pvrusb2/pvrusb2-context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/pvrusb2/pvrusb2-context.c b/drivers/media/usb/pvrusb2/pvrusb2-context.c index 9236463ba269..89897cb7d29b 100644 --- a/drivers/media/usb/pvrusb2/pvrusb2-context.c +++ b/drivers/media/usb/pvrusb2/pvrusb2-context.c @@ -276,9 +276,9 @@ static void pvr2_context_exit(struct pvr2_context *mp) void pvr2_context_disconnect(struct pvr2_context *mp) { pvr2_hdw_disconnect(mp->hdw); - mp->disconnect_flag = !0; if (!pvr2_context_shutok()) pvr2_context_notify(mp); + mp->disconnect_flag = !0; } -- 2.34.1

2 1

[PATCH OLK-6.6] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
by ZhaoLong Wang 23 Apr '24

23 Apr '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.9-rc1 commit 3948abaa4e2be938ccdfc289385a27342fb13d43 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK1I CVE: CVE-2024-26901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III <chuck.lever(a)oracle.com> Reported-and-tested-by: <syzbot+09b349b3066c2e0b1e96(a)syzkaller.appspotmail.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintech.ru Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 6ea8d35a9382..99dcf07cfecf 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -40,7 +40,7 @@ static long do_sys_name_to_handle(const struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; - handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM; -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
by ZhaoLong Wang 23 Apr '24

23 Apr '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.9-rc1 commit 3948abaa4e2be938ccdfc289385a27342fb13d43 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK1I CVE: CVE-2024-26901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III <chuck.lever(a)oracle.com> Reported-and-tested-by: <syzbot+09b349b3066c2e0b1e96(a)syzkaller.appspotmail.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintech.ru Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 0ee727485615..cb78dbfd7cd5 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -37,7 +37,7 @@ static long do_sys_name_to_handle(struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; - handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM; -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP2] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
by ZhaoLong Wang 23 Apr '24

23 Apr '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.9-rc1 commit 3948abaa4e2be938ccdfc289385a27342fb13d43 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK1I CVE: CVE-2024-26901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III <chuck.lever(a)oracle.com> Reported-and-tested-by: <syzbot+09b349b3066c2e0b1e96(a)syzkaller.appspotmail.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintech.ru Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 718defdf1e0e..744ae0dba99c 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -37,7 +37,7 @@ static long do_sys_name_to_handle(struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; - handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM; -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
by ZhaoLong Wang 23 Apr '24

23 Apr '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.9-rc1 commit 3948abaa4e2be938ccdfc289385a27342fb13d43 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK1I CVE: CVE-2024-26901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III <chuck.lever(a)oracle.com> Reported-and-tested-by: <syzbot+09b349b3066c2e0b1e96(a)syzkaller.appspotmail.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintech.ru Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 718defdf1e0e..744ae0dba99c 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -37,7 +37,7 @@ static long do_sys_name_to_handle(struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; - handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM; -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
by ZhaoLong Wang 23 Apr '24

23 Apr '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.9-rc1 commit 3948abaa4e2be938ccdfc289385a27342fb13d43 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK1I CVE: CVE-2024-26901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III <chuck.lever(a)oracle.com> Reported-and-tested-by: <syzbot+09b349b3066c2e0b1e96(a)syzkaller.appspotmail.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintech.ru Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 718defdf1e0e..744ae0dba99c 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -37,7 +37,7 @@ static long do_sys_name_to_handle(struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; - handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM; -- 2.39.2

2 1

[PATCH OLK-5.10] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
by ZhaoLong Wang 23 Apr '24

23 Apr '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.9-rc1 commit 3948abaa4e2be938ccdfc289385a27342fb13d43 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK1I CVE: CVE-2024-26901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III <chuck.lever(a)oracle.com> Reported-and-tested-by: <syzbot+09b349b3066c2e0b1e96(a)syzkaller.appspotmail.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintech.ru Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 718defdf1e0e..744ae0dba99c 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -37,7 +37,7 @@ static long do_sys_name_to_handle(struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; - handle = kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle = kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM; -- 2.39.2

2 1

[PATCH OLK-5.10] nvme-fc: do not wait in vain when unloading module
by Li Lingfeng 23 Apr '24

23 Apr '24

From: Daniel Wagner <dwagner(a)suse.de> stable inclusion from stable-v5.10.211 commit 4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJSI CVE: CVE-2024-26846 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 70fbfc47a392b98e5f8dba70c6efc6839205c982 ] The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. This is done by flushing the nvme_delete_wq workqueue. While at it, remove the unused nvme_fc_wq workqueue too. Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Daniel Wagner <dwagner(a)suse.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/nvme/host/fc.c | 47 ++++++------------------------------------ 1 file changed, 6 insertions(+), 41 deletions(-) diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c index b534a85e2bf1..92db88ceb96f 100644 --- a/drivers/nvme/host/fc.c +++ b/drivers/nvme/host/fc.c @@ -220,11 +220,6 @@ static LIST_HEAD(nvme_fc_lport_list); static DEFINE_IDA(nvme_fc_local_port_cnt); static DEFINE_IDA(nvme_fc_ctrl_cnt); -static struct workqueue_struct *nvme_fc_wq; - -static bool nvme_fc_waiting_to_unload; -static DECLARE_COMPLETION(nvme_fc_unload_proceed); - /* * These items are short-term. They will eventually be moved into * a generic FC class. See comments in module init. @@ -254,8 +249,6 @@ nvme_fc_free_lport(struct kref *ref) /* remove from transport list */ spin_lock_irqsave(&nvme_fc_lock, flags); list_del(&lport->port_list); - if (nvme_fc_waiting_to_unload && list_empty(&nvme_fc_lport_list)) - complete(&nvme_fc_unload_proceed); spin_unlock_irqrestore(&nvme_fc_lock, flags); ida_simple_remove(&nvme_fc_local_port_cnt, lport->localport.port_num); @@ -3823,10 +3816,6 @@ static int __init nvme_fc_init_module(void) { int ret; - nvme_fc_wq = alloc_workqueue("nvme_fc_wq", WQ_MEM_RECLAIM, 0); - if (!nvme_fc_wq) - return -ENOMEM; - /* * NOTE: * It is expected that in the future the kernel will combine @@ -3844,7 +3833,7 @@ static int __init nvme_fc_init_module(void) ret = class_register(&fc_class); if (ret) { pr_err("couldn't register class fc\n"); - goto out_destroy_wq; + return ret; } /* @@ -3868,8 +3857,6 @@ static int __init nvme_fc_init_module(void) device_destroy(&fc_class, MKDEV(0, 0)); out_destroy_class: class_unregister(&fc_class); -out_destroy_wq: - destroy_workqueue(nvme_fc_wq); return ret; } @@ -3889,45 +3876,23 @@ nvme_fc_delete_controllers(struct nvme_fc_rport *rport) spin_unlock(&rport->lock); } -static void -nvme_fc_cleanup_for_unload(void) +static void __exit nvme_fc_exit_module(void) { struct nvme_fc_lport *lport; struct nvme_fc_rport *rport; - - list_for_each_entry(lport, &nvme_fc_lport_list, port_list) { - list_for_each_entry(rport, &lport->endp_list, endp_list) { - nvme_fc_delete_controllers(rport); - } - } -} - -static void __exit nvme_fc_exit_module(void) -{ unsigned long flags; - bool need_cleanup = false; spin_lock_irqsave(&nvme_fc_lock, flags); - nvme_fc_waiting_to_unload = true; - if (!list_empty(&nvme_fc_lport_list)) { - need_cleanup = true; - nvme_fc_cleanup_for_unload(); - } + list_for_each_entry(lport, &nvme_fc_lport_list, port_list) + list_for_each_entry(rport, &lport->endp_list, endp_list) + nvme_fc_delete_controllers(rport); spin_unlock_irqrestore(&nvme_fc_lock, flags); - if (need_cleanup) { - pr_info("%s: waiting for ctlr deletes\n", __func__); - wait_for_completion(&nvme_fc_unload_proceed); - pr_info("%s: ctrl deletes complete\n", __func__); - } + flush_workqueue(nvme_delete_wq); nvmf_unregister_transport(&nvme_fc_transport); - ida_destroy(&nvme_fc_local_port_cnt); - ida_destroy(&nvme_fc_ctrl_cnt); - device_destroy(&fc_class, MKDEV(0, 0)); class_unregister(&fc_class); - destroy_workqueue(nvme_fc_wq); } module_init(nvme_fc_init_module); -- 2.31.1

2 1

2024

2023

2022

2021

2020

2019

Kernel April 2024