- Kernel - mailweb.openeuler.org

[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: 189815 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: 189815 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: 189815 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-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: 189815 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: 189815 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-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: 189815 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 OLK-5.10 0/2] CVE-2024-26813
by Liu Mingrui 23 Apr '24

23 Apr '24

CVE-2024-26813 Alex Williamson (2): vfio/platform: Disable virqfds on cleanup vfio/platform: Create persistent IRQ handlers drivers/vfio/platform/vfio_platform_irq.c | 106 +++++++++++++++------- 1 file changed, 72 insertions(+), 34 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-26813
by Liu Mingrui 23 Apr '24

23 Apr '24

CVE-2024-26813 Alex Williamson (2): vfio/platform: Disable virqfds on cleanup vfio/platform: Create persistent IRQ handlers drivers/vfio/platform/vfio_platform_irq.c | 106 +++++++++++++++------- 1 file changed, 72 insertions(+), 34 deletions(-) -- 2.25.1

2 3

[OLK-6.6 0/5] Some bugfixes and cleanups
by Chengchang Tang 23 Apr '24

23 Apr '24

From: Juan Zhou <zhoujuan51(a)h-partners.com> Some bugfixes and cleanups. Juan Zhou (1): RDMA/hns: Fix incorrect variable usage in scc_attr_is_visible() Junxian Huang (1): RDMA/hns: Fix a potential Sleep-in-Atomic-Context wenglianfa (3): RDMA/hns: Add mutex_destroy() to destroy the mutex RDMA/hns : Fix scc_param delay_work to execute after sysfs shutdown RDMA/hns : Fix null pointer when alloc_scc_param() fails drivers/infiniband/hw/hns/hns_roce_bond.c | 2 ++ drivers/infiniband/hw/hns/hns_roce_device.h | 4 +-- drivers/infiniband/hw/hns/hns_roce_main.c | 13 ++++++-- drivers/infiniband/hw/hns/hns_roce_sysfs.c | 36 ++++++++++----------- 4 files changed, 32 insertions(+), 23 deletions(-) -- 2.30.0

1 5

[PATCH openEuler-1.0-LTS V3 0/2] Fix CVE-2024-26869
by Zizhi Wo 23 Apr '24

23 Apr '24

V3: fix one missing issue in do_write_page() V2: fix one missing issue in f2fs_invalidate_blocks() V1: fix main error Chao Yu (2): Revert: "f2fs: check last page index in cached bio to decide submission" f2fs: fix to truncate meta inode pages forcely fs/f2fs/checkpoint.c | 3 +-- fs/f2fs/data.c | 41 ++++++++++++++++++++--------------------- fs/f2fs/f2fs.h | 30 ++++++++++++++++++++++++++++-- fs/f2fs/gc.c | 3 +-- fs/f2fs/node.c | 11 +++++------ fs/f2fs/segment.c | 19 ++++++++----------- include/linux/f2fs_fs.h | 1 + 7 files changed, 64 insertions(+), 44 deletions(-) -- 2.39.2

2 3