- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS] cachefiles: fix memory leak in cachefiles_add_cache()
by Baokun Li 23 Apr '24

23 Apr '24

stable inclusion from stable-v5.10.212 commit 43eccc5823732ba6daab2511ed32dfc545a666d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJVQ CVE: CVE-2024-26840 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e21a2f17566cbd64926fb8f16323972f7a064444 upstream. The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") CC: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Link: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com Acked-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jingbo Xu <jefflexu(a)linux.alibaba.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/cachefiles/bind.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/cachefiles/bind.c b/fs/cachefiles/bind.c index dfb14dbddf51..3b39552c2365 100644 --- a/fs/cachefiles/bind.c +++ b/fs/cachefiles/bind.c @@ -245,6 +245,8 @@ static int cachefiles_daemon_add_cache(struct cachefiles_cache *cache) kmem_cache_free(cachefiles_object_jar, fsdef); error_root_object: cachefiles_end_secure(cache, saved_cred); + put_cred(cache->cache_cred); + cache->cache_cred = NULL; pr_err("Failed to register: %d\n", ret); return ret; } @@ -265,6 +267,7 @@ void cachefiles_daemon_unbind(struct cachefiles_cache *cache) dput(cache->graveyard); mntput(cache->mnt); + put_cred(cache->cache_cred); kfree(cache->rootdirname); kfree(cache->secctx); -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] 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> mainline inclusion from mainline-v6.8-rc3 commit 70fbfc47a392b98e5f8dba70c6efc6839205c982 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/torvalds/linux.git/commit/?… -------------------------------- 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> Conflict: drivers/nvme/host/fc.c Commit 97faec531460("nvme_fc: add 'nvme_discovery' sysfs attribute to fc transport device") define static fc_class and replace class_destroy with class_unregister to release fc_class; Commit 3dd83f4013f0("nvme-fc: replace ida_simple[get|remove] with the simler ida_[alloc|free]") replace ida_simple_remove with the simler ida_free; Commit 9c2bb2577d81("nvme-fc: remove err_work work item") remove the use of nvme_fc_wq. Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/nvme/host/fc.c | 36 +++++------------------------------- 1 file changed, 5 insertions(+), 31 deletions(-) diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c index 8cc714c4c35c..476a267e090a 100644 --- a/drivers/nvme/host/fc.c +++ b/drivers/nvme/host/fc.c @@ -211,9 +211,6 @@ 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. @@ -240,8 +237,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); @@ -3416,42 +3411,21 @@ 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_destroy(fc_class); destroy_workqueue(nvme_fc_wq); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] cachefiles: fix memory leak in cachefiles_add_cache()
by Baokun Li 23 Apr '24

23 Apr '24

stable inclusion from stable-v5.10.212 commit 43eccc5823732ba6daab2511ed32dfc545a666d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJVQ CVE: CVE-2024-26840 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e21a2f17566cbd64926fb8f16323972f7a064444 upstream. The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") CC: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Link: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com Acked-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jingbo Xu <jefflexu(a)linux.alibaba.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/cachefiles/bind.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/cachefiles/bind.c b/fs/cachefiles/bind.c index dfb14dbddf51..3b39552c2365 100644 --- a/fs/cachefiles/bind.c +++ b/fs/cachefiles/bind.c @@ -245,6 +245,8 @@ static int cachefiles_daemon_add_cache(struct cachefiles_cache *cache) kmem_cache_free(cachefiles_object_jar, fsdef); error_root_object: cachefiles_end_secure(cache, saved_cred); + put_cred(cache->cache_cred); + cache->cache_cred = NULL; pr_err("Failed to register: %d\n", ret); return ret; } @@ -265,6 +267,7 @@ void cachefiles_daemon_unbind(struct cachefiles_cache *cache) dput(cache->graveyard); mntput(cache->mnt); + put_cred(cache->cache_cred); kfree(cache->rootdirname); kfree(cache->secctx); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP2] cachefiles: fix memory leak in cachefiles_add_cache()
by Baokun Li 23 Apr '24

23 Apr '24

stable inclusion from stable-v5.10.212 commit 43eccc5823732ba6daab2511ed32dfc545a666d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJVQ CVE: CVE-2024-26840 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e21a2f17566cbd64926fb8f16323972f7a064444 upstream. The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") CC: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Link: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com Acked-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jingbo Xu <jefflexu(a)linux.alibaba.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/cachefiles/bind.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/cachefiles/bind.c b/fs/cachefiles/bind.c index dfb14dbddf51..3b39552c2365 100644 --- a/fs/cachefiles/bind.c +++ b/fs/cachefiles/bind.c @@ -245,6 +245,8 @@ static int cachefiles_daemon_add_cache(struct cachefiles_cache *cache) kmem_cache_free(cachefiles_object_jar, fsdef); error_root_object: cachefiles_end_secure(cache, saved_cred); + put_cred(cache->cache_cred); + cache->cache_cred = NULL; pr_err("Failed to register: %d\n", ret); return ret; } @@ -265,6 +267,7 @@ void cachefiles_daemon_unbind(struct cachefiles_cache *cache) dput(cache->graveyard); mntput(cache->mnt); + put_cred(cache->cache_cred); kfree(cache->rootdirname); kfree(cache->secctx); -- 2.31.1

2 1

[PATCH OLK-5.10] cachefiles: fix memory leak in cachefiles_add_cache()
by Baokun Li 23 Apr '24

23 Apr '24

stable inclusion from stable-v5.10.212 commit 43eccc5823732ba6daab2511ed32dfc545a666d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJVQ CVE: CVE-2024-26840 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e21a2f17566cbd64926fb8f16323972f7a064444 upstream. The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks. Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem") CC: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Link: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com Acked-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Jingbo Xu <jefflexu(a)linux.alibaba.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/cachefiles/bind.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/cachefiles/bind.c b/fs/cachefiles/bind.c index dfb14dbddf51..3b39552c2365 100644 --- a/fs/cachefiles/bind.c +++ b/fs/cachefiles/bind.c @@ -245,6 +245,8 @@ static int cachefiles_daemon_add_cache(struct cachefiles_cache *cache) kmem_cache_free(cachefiles_object_jar, fsdef); error_root_object: cachefiles_end_secure(cache, saved_cred); + put_cred(cache->cache_cred); + cache->cache_cred = NULL; pr_err("Failed to register: %d\n", ret); return ret; } @@ -265,6 +267,7 @@ void cachefiles_daemon_unbind(struct cachefiles_cache *cache) dput(cache->graveyard); mntput(cache->mnt); + put_cred(cache->cache_cred); kfree(cache->rootdirname); kfree(cache->secctx); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS v2 0/4] Add hugetlb MADV_DONTNEED support
by Ze Zuo 23 Apr '24

23 Apr '24

MADV_DONTNEED is currently disabled for hugetlb mappings. This certainly makes sense in shared file mappings as the pagecache maintains a reference to the page and it will never be freed. However, it could be useful to unmap and free pages in private mappings. v1->v2: Add patch to fix race caused by enabling the madv_dontneed feature. Mike Kravetz (3): mm: enable MADV_DONTNEED for hugetlb mappings madvise: use zap_page_range_single for madvise dontneed hugetlb: don't delete vma_lock in hugetlb MADV_DONTNEED processing Rik van Riel (1): mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs include/linux/hugetlb.h | 5 +++-- include/linux/mm.h | 6 +++++ include/linux/mm_types.h | 2 ++ mm/hugetlb.c | 28 ++++++++++++++---------- mm/madvise.c | 47 +++++++++++++++++++++++++++++++++++----- mm/memory.c | 23 +++++++++++++++----- 6 files changed, 87 insertions(+), 24 deletions(-) -- 2.25.1

2 5

[PATCH openEuler-1.0-LTS] RDMA/srpt: Do not register event handler until srpt device is fully setup
by Zhengchao Shao 23 Apr '24

23 Apr '24

From: William Kucharski <william.kucharski(a)oracle.com> mainline inclusion from mainline-v6.9-rc1 commit c21a8870c98611e8f892511825c9607f1e2cd456 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK8Y CVE: CVE-2024-26872 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete. Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1") Signed-off-by: William Kucharski <william.kucharski(a)oracle.com> Link: https://lore.kernel.org/r/20240202091549.991784-2-william.kucharski@oracle.… Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/ulp/srpt/ib_srpt.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/infiniband/ulp/srpt/ib_srpt.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c index 7550c9777ed1..4948d5b446b6 100644 --- a/drivers/infiniband/ulp/srpt/ib_srpt.c +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c @@ -3058,7 +3058,6 @@ static void srpt_add_one(struct ib_device *device) INIT_IB_EVENT_HANDLER(&sdev->event_handler, sdev->device, srpt_event_handler); - ib_register_event_handler(&sdev->event_handler); for (i = 1; i <= sdev->device->phys_port_cnt; i++) { sport = &sdev->port[i - 1]; @@ -3076,10 +3075,11 @@ static void srpt_add_one(struct ib_device *device) if (srpt_refresh_port(sport)) { pr_err("MAD registration failed for %s-%d.\n", sdev->device->name, i); - goto err_event; + goto err_cm; } } + ib_register_event_handler(&sdev->event_handler); spin_lock(&srpt_dev_lock); list_add_tail(&sdev->list, &srpt_dev_list); spin_unlock(&srpt_dev_lock); @@ -3089,8 +3089,6 @@ static void srpt_add_one(struct ib_device *device) pr_debug("added %s.\n", device->name); return; -err_event: - ib_unregister_event_handler(&sdev->event_handler); err_cm: if (sdev->cm_id) ib_destroy_cm_id(sdev->cm_id); -- 2.34.1

2 1

[PATCH v2 openEuler-1.0-LTS 0/3] oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup
by Wupeng Ma 23 Apr '24

23 Apr '24

From: Ma Wupeng <mawupeng1(a)huawei.com> delay the OOM reaper to allow time for proper futex cleanup. Changelog since v1: - move oom_reaper_timer in struct struct task_struct_resvd. Ma Wupeng (1): mm: oom_kill: fix KABI broken by "oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup" Nico Pache (1): oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup Zheng Zucheng (1): sched: Allocate a new task_struct_resvd object for fork task include/linux/sched.h | 23 ++++++++++---- include/linux/sched/grid_qos.h | 2 +- init/init_task.c | 5 ++++ kernel/fork.c | 21 ++++++++++++- kernel/sched/grid/qos.c | 20 ++++++------- mm/oom_kill.c | 55 +++++++++++++++++++++++++--------- 6 files changed, 95 insertions(+), 31 deletions(-) -- 2.25.1

2 4

[PATCH OLK-5.10] RDMA/srpt: Do not register event handler until srpt device is fully setup
by Zhengchao Shao 23 Apr '24

23 Apr '24

From: William Kucharski <william.kucharski(a)oracle.com> stable inclusion from stable-v5.10.214 commit bdd895e0190c464f54f84579e7535d80276f0fc5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK8Y CVE: CVE-2024-26872 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c21a8870c98611e8f892511825c9607f1e2cd456 ] Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete. Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1") Signed-off-by: William Kucharski <william.kucharski(a)oracle.com> Link: https://lore.kernel.org/r/20240202091549.991784-2-william.kucharski@oracle.… Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/infiniband/ulp/srpt/ib_srpt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c index 80e99e9e9717..7001082d8ecd 100644 --- a/drivers/infiniband/ulp/srpt/ib_srpt.c +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c @@ -3204,7 +3204,6 @@ static int srpt_add_one(struct ib_device *device) INIT_IB_EVENT_HANDLER(&sdev->event_handler, sdev->device, srpt_event_handler); - ib_register_event_handler(&sdev->event_handler); for (i = 1; i <= sdev->device->phys_port_cnt; i++) { sport = &sdev->port[i - 1]; @@ -3227,6 +3226,7 @@ static int srpt_add_one(struct ib_device *device) } } + ib_register_event_handler(&sdev->event_handler); spin_lock(&srpt_dev_lock); list_add_tail(&sdev->list, &srpt_dev_list); spin_unlock(&srpt_dev_lock); @@ -3237,7 +3237,6 @@ static int srpt_add_one(struct ib_device *device) err_port: srpt_unregister_mad_agent(sdev, i); - ib_unregister_event_handler(&sdev->event_handler); err_cm: if (sdev->cm_id) ib_destroy_cm_id(sdev->cm_id); -- 2.34.1

2 1

[PATCH OLK-6.6] btrfs: fix data races when accessing the reserved amount of block reserves
by Baokun Li 23 Apr '24

23 Apr '24

From: Filipe Manana <fdmanana(a)suse.com> stable inclusion from stable-v6.6.23 commit 82220b1835baaebf4ae2e490f56353a341a09bd2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HKBL CVE: CVE-2024-26905 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e06cc89475eddc1f3a7a4d471524256152c68166 ] At space_info.c we have several places where we access the ->reserved field of a block reserve without taking the block reserve's spinlock first, which makes KCSAN warn about a data race since that field is always updated while holding the spinlock. The reports from KCSAN are like the following: [117.193526] BUG: KCSAN: data-race in btrfs_block_rsv_release [btrfs] / need_preemptive_reclaim [btrfs] [117.195148] read to 0x000000017f587190 of 8 bytes by task 6303 on cpu 3: [117.195172] need_preemptive_reclaim+0x222/0x2f0 [btrfs] [117.195992] __reserve_bytes+0xbb0/0xdc8 [btrfs] [117.196807] btrfs_reserve_metadata_bytes+0x4c/0x120 [btrfs] [117.197620] btrfs_block_rsv_add+0x78/0xa8 [btrfs] [117.198434] btrfs_delayed_update_inode+0x154/0x368 [btrfs] [117.199300] btrfs_update_inode+0x108/0x1c8 [btrfs] [117.200122] btrfs_dirty_inode+0xb4/0x140 [btrfs] [117.200937] btrfs_update_time+0x8c/0xb0 [btrfs] [117.201754] touch_atime+0x16c/0x1e0 [117.201789] filemap_read+0x674/0x728 [117.201823] btrfs_file_read_iter+0xf8/0x410 [btrfs] [117.202653] vfs_read+0x2b6/0x498 [117.203454] ksys_read+0xa2/0x150 [117.203473] __s390x_sys_read+0x68/0x88 [117.203495] do_syscall+0x1c6/0x210 [117.203517] __do_syscall+0xc8/0xf0 [117.203539] system_call+0x70/0x98 [117.203579] write to 0x000000017f587190 of 8 bytes by task 11 on cpu 0: [117.203604] btrfs_block_rsv_release+0x2e8/0x578 [btrfs] [117.204432] btrfs_delayed_inode_release_metadata+0x7c/0x1d0 [btrfs] [117.205259] __btrfs_update_delayed_inode+0x37c/0x5e0 [btrfs] [117.206093] btrfs_async_run_delayed_root+0x356/0x498 [btrfs] [117.206917] btrfs_work_helper+0x160/0x7a0 [btrfs] [117.207738] process_one_work+0x3b6/0x838 [117.207768] worker_thread+0x75e/0xb10 [117.207797] kthread+0x21a/0x230 [117.207830] __ret_from_fork+0x6c/0xb8 [117.207861] ret_from_fork+0xa/0x30 So add a helper to get the reserved amount of a block reserve while holding the lock. The value may be not be up to date anymore when used by need_preemptive_reclaim() and btrfs_preempt_reclaim_metadata_space(), but that's ok since the worst it can do is cause more reclaim work do be done sooner rather than later. Reading the field while holding the lock instead of using the data_race() annotation is used in order to prevent load tearing. Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/block-rsv.h | 16 ++++++++++++++++ fs/btrfs/space-info.c | 26 +++++++++++++------------- 2 files changed, 29 insertions(+), 13 deletions(-) diff --git a/fs/btrfs/block-rsv.h b/fs/btrfs/block-rsv.h index b0bd12b8652f..fb440a074700 100644 --- a/fs/btrfs/block-rsv.h +++ b/fs/btrfs/block-rsv.h @@ -101,4 +101,20 @@ static inline bool btrfs_block_rsv_full(const struct btrfs_block_rsv *rsv) return data_race(rsv->full); } +/* + * Get the reserved mount of a block reserve in a context where getting a stale + * value is acceptable, instead of accessing it directly and trigger data race + * warning from KCSAN. + */ +static inline u64 btrfs_block_rsv_reserved(struct btrfs_block_rsv *rsv) +{ + u64 ret; + + spin_lock(&rsv->lock); + ret = rsv->reserved; + spin_unlock(&rsv->lock); + + return ret; +} + #endif /* BTRFS_BLOCK_RSV_H */ diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c index d7e8cd4f140c..3f7a9605e2d3 100644 --- a/fs/btrfs/space-info.c +++ b/fs/btrfs/space-info.c @@ -837,7 +837,7 @@ btrfs_calc_reclaim_metadata_size(struct btrfs_fs_info *fs_info, static bool need_preemptive_reclaim(struct btrfs_fs_info *fs_info, struct btrfs_space_info *space_info) { - u64 global_rsv_size = fs_info->global_block_rsv.reserved; + const u64 global_rsv_size = btrfs_block_rsv_reserved(&fs_info->global_block_rsv); u64 ordered, delalloc; u64 thresh; u64 used; @@ -937,8 +937,8 @@ static bool need_preemptive_reclaim(struct btrfs_fs_info *fs_info, ordered = percpu_counter_read_positive(&fs_info->ordered_bytes) >> 1; delalloc = percpu_counter_read_positive(&fs_info->delalloc_bytes); if (ordered >= delalloc) - used += fs_info->delayed_refs_rsv.reserved + - fs_info->delayed_block_rsv.reserved; + used += btrfs_block_rsv_reserved(&fs_info->delayed_refs_rsv) + + btrfs_block_rsv_reserved(&fs_info->delayed_block_rsv); else used += space_info->bytes_may_use - global_rsv_size; @@ -1153,7 +1153,7 @@ static void btrfs_preempt_reclaim_metadata_space(struct work_struct *work) enum btrfs_flush_state flush; u64 delalloc_size = 0; u64 to_reclaim, block_rsv_size; - u64 global_rsv_size = global_rsv->reserved; + const u64 global_rsv_size = btrfs_block_rsv_reserved(global_rsv); loops++; @@ -1165,9 +1165,9 @@ static void btrfs_preempt_reclaim_metadata_space(struct work_struct *work) * assume it's tied up in delalloc reservations. */ block_rsv_size = global_rsv_size + - delayed_block_rsv->reserved + - delayed_refs_rsv->reserved + - trans_rsv->reserved; + btrfs_block_rsv_reserved(delayed_block_rsv) + + btrfs_block_rsv_reserved(delayed_refs_rsv) + + btrfs_block_rsv_reserved(trans_rsv); if (block_rsv_size < space_info->bytes_may_use) delalloc_size = space_info->bytes_may_use - block_rsv_size; @@ -1187,16 +1187,16 @@ static void btrfs_preempt_reclaim_metadata_space(struct work_struct *work) to_reclaim = delalloc_size; flush = FLUSH_DELALLOC; } else if (space_info->bytes_pinned > - (delayed_block_rsv->reserved + - delayed_refs_rsv->reserved)) { + (btrfs_block_rsv_reserved(delayed_block_rsv) + + btrfs_block_rsv_reserved(delayed_refs_rsv))) { to_reclaim = space_info->bytes_pinned; flush = COMMIT_TRANS; - } else if (delayed_block_rsv->reserved > - delayed_refs_rsv->reserved) { - to_reclaim = delayed_block_rsv->reserved; + } else if (btrfs_block_rsv_reserved(delayed_block_rsv) > + btrfs_block_rsv_reserved(delayed_refs_rsv)) { + to_reclaim = btrfs_block_rsv_reserved(delayed_block_rsv); flush = FLUSH_DELAYED_ITEMS_NR; } else { - to_reclaim = delayed_refs_rsv->reserved; + to_reclaim = btrfs_block_rsv_reserved(delayed_refs_rsv); flush = FLUSH_DELAYED_REFS_NR; } -- 2.31.1

2 1

[PATCH OLK-5.10 V2 0/4] Fix CVE-2024-26869
by Zizhi Wo 23 Apr '24

23 Apr '24

V2: merge some missing patches. V1: fix main error. Chao Yu (3): f2fs: fix to invalidate META_MAPPING before DIO write f2fs: invalidate meta pages only for post_read required inode f2fs: fix to truncate meta inode pages forcely Hyeong-Jun Kim (1): f2fs: invalidate META_MAPPING before IPU/DIO write fs/f2fs/checkpoint.c | 5 +++-- fs/f2fs/data.c | 4 ++-- fs/f2fs/f2fs.h | 27 +++++++++++++++++++++++++++ fs/f2fs/gc.c | 3 +-- fs/f2fs/segment.c | 17 ++++++++++++----- include/linux/f2fs_fs.h | 1 + 6 files changed, 46 insertions(+), 11 deletions(-) -- 2.39.2

2 5

[PATCH OLK-5.10] devlink: fix possible use-after-free and memory leaks in devlink_init()
by Jialin Zhang 23 Apr '24

23 Apr '24

From: Vasiliy Kovalev <kovalev(a)altlinux.org> mainline inclusion from mainline-v6.8-rc6 commit def689fc26b9a9622d2e2cb0c4933dd3b1c8071c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2M1 CVE: CVE-2024-26734 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The pernet operations structure for the subsystem must be registered before registering the generic netlink family. Make an unregister in case of unsuccessful registration. Fixes: 687125b5799c ("devlink: split out core code") Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> Link: https://lore.kernel.org/r/20240215203400.29976-1-kovalev@altlinux.org Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/core/devlink.c Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- net/core/devlink.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/core/devlink.c b/net/core/devlink.c index 38666dde8934..99939fb05ca9 100644 --- a/net/core/devlink.c +++ b/net/core/devlink.c @@ -10340,10 +10340,14 @@ static int __init devlink_init(void) { int err; - err = genl_register_family(&devlink_nl_family); + err = register_pernet_subsys(&devlink_pernet_ops); if (err) goto out; - err = register_pernet_subsys(&devlink_pernet_ops); + err = genl_register_family(&devlink_nl_family); + if (!err) + return 0; + + unregister_pernet_subsys(&devlink_pernet_ops); out: WARN_ON(err); -- 2.25.1

2 1

[PATCH OLK-5.10 0/1] CVE-2024-26843
by Yongqiang Liu 23 Apr '24

23 Apr '24

Andrew Bresticker (1): efi: runtime: Fix potential overflow of soft-reserved region size drivers/firmware/efi/arm-runtime.c | 2 +- drivers/firmware/efi/riscv-runtime.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6] LoongArch: fix boot error caused by ioremap_page_range error
by Hongchen Zhang 23 Apr '24

23 Apr '24

LoongArch inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9IJVV ------------------------------------------ use vmap_page_range to map pci address space instead of ioremap_page_range. Fixes: ae528eb14e9a ("mm: Introduce vmap_page_range() to map pages in PCI address space") Signed-off-by: Hongchen Zhang <zhanghongchen(a)loongson.cn> --- arch/loongarch/kernel/legacy_boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/loongarch/kernel/legacy_boot.c b/arch/loongarch/kernel/legacy_boot.c index 35a0a118486f..29fdeb93dfd5 100644 --- a/arch/loongarch/kernel/legacy_boot.c +++ b/arch/loongarch/kernel/legacy_boot.c @@ -436,7 +436,7 @@ static int __init add_legacy_isa_io(struct fwnode_handle *fwnode, unsigned long } vaddr = (unsigned long)(PCI_IOBASE + range->io_start); - ret = ioremap_page_range(vaddr, vaddr + range->size, range->hw_start, + ret = vmap_page_range(vaddr, vaddr + range->size, range->hw_start, pgprot_device(PAGE_KERNEL)); return ret; } -- 2.33.0

2 1

[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

[PATCH OLK-5.10] [Backport] firmware: arm_scmi: Fix double free in SMC transport cleanup path
by Zhenzeng Su 23 Apr '24

23 Apr '24

From: Andre Przywara <andre.przywara(a)arm.com> mainline inclusion from mainline-v6.9-rc1 commit f1d71576d2c9ec8fdb822173fa7f3de79475e9bd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK9F CVE: CVE-2024-26893 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport") Reviewed-by: Cristian Marussi <cristian.marussi(a)arm.com> Link: https://lore.kernel.org/r/20240126122325.2039669-1-andre.przywara@arm.com Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com> --- drivers/firmware/arm_scmi/smc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c index 82a82a5dc86a..e18bddb063d8 100644 --- a/drivers/firmware/arm_scmi/smc.c +++ b/drivers/firmware/arm_scmi/smc.c @@ -92,6 +92,13 @@ static int smc_chan_free(int id, void *p, void *data) struct scmi_chan_info *cinfo = p; struct scmi_smc *scmi_info = cinfo->transport_info; + /* + * Different protocols might share the same chan info, so a previous + * smc_chan_free call might have already freed the structure. + */ + if (!scmi_info) + return 0; + cinfo->transport_info = NULL; scmi_info->cinfo = NULL; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/1] fix race between domains rebuild and hotplug
by Chen Ridong 23 Apr '24

23 Apr '24

*** BLURB HERE *** Chen Ridong (1): cpuset: fix race between rebuild scheduler domains and hotplug work kernel/cgroup/cpuset.c | 7 +++++++ 1 file changed, 7 insertions(+) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP2] cpufreq: CPPC: Fix performance/frequency conversion
by Zeng Heng 23 Apr '24

23 Apr '24

From: Pierre Gondois <Pierre.Gondois(a)arm.com> mainline inclusion from mainline-v5.18-rc1 commit ec1c7ad47664f964c1101fe555b6fde0cb124b38 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8WAED Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- CPUfreq governors request CPU frequencies using information on current CPU usage. The CPPC driver converts them to performance requests. Frequency targets are computed as: target_freq = (util / cpu_capacity) * max_freq target_freq is then clamped between [policy->min, policy->max]. The CPPC driver converts performance values to frequencies (and vice-versa) using cppc_cpufreq_perf_to_khz() and cppc_cpufreq_khz_to_perf(). These functions both use two different factors depending on the range of the input value. For cppc_cpufreq_khz_to_perf(): - (NOMINAL_PERF / NOMINAL_FREQ) or - (LOWEST_PERF / LOWEST_FREQ) and for cppc_cpufreq_perf_to_khz(): - (NOMINAL_FREQ / NOMINAL_PERF) or - ((NOMINAL_PERF - LOWEST_FREQ) / (NOMINAL_PERF - LOWEST_PERF)) This means: 1- the functions are not inverse for some values: (perf_to_khz(khz_to_perf(x)) != x) 2- cppc_cpufreq_perf_to_khz(LOWEST_PERF) can sometimes give a different value from LOWEST_FREQ due to integer approximation 3- it is implied that performance and frequency are proportional (NOMINAL_FREQ / NOMINAL_PERF) == (LOWEST_PERF / LOWEST_FREQ) This patch changes the conversion functions to an affine function. This fixes the 3 points above. Suggested-by: Lukasz Luba <lukasz.luba(a)arm.com> Suggested-by: Morten Rasmussen <morten.rasmussen(a)arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois(a)arm.com> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/cpufreq/cppc_cpufreq.c | 43 +++++++++++++++++----------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index f7f3632dcf31..bb955318c024 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -89,35 +89,34 @@ static u64 cppc_get_dmi_max_khz(void) /* * If CPPC lowest_freq and nominal_freq registers are exposed then we can - * use them to convert perf to freq and vice versa - * - * If the perf/freq point lies between Nominal and Lowest, we can treat - * (Low perf, Low freq) and (Nom Perf, Nom freq) as 2D co-ordinates of a line - * and extrapolate the rest - * For perf/freq > Nominal, we use the ratio perf:freq at Nominal for conversion + * use them to convert perf to freq and vice versa. The conversion is + * extrapolated as an affine function passing by the 2 points: + * - (Low perf, Low freq) + * - (Nominal perf, Nominal perf) */ static unsigned int cppc_cpufreq_perf_to_khz(struct cppc_cpudata *cpu, unsigned int perf) { static u64 max_khz; struct cppc_perf_caps *caps = &cpu->perf_caps; + s64 retval, offset = 0; u64 mul, div; if (caps->lowest_freq && caps->nominal_freq) { - if (perf >= caps->nominal_perf) { - mul = caps->nominal_freq; - div = caps->nominal_perf; - } else { - mul = caps->nominal_freq - caps->lowest_freq; - div = caps->nominal_perf - caps->lowest_perf; - } + mul = caps->nominal_freq - caps->lowest_freq; + div = caps->nominal_perf - caps->lowest_perf; + offset = caps->nominal_freq - div64_u64(caps->nominal_perf * mul, div); } else { if (!max_khz) max_khz = cppc_get_dmi_max_khz(); mul = max_khz; div = caps->highest_perf; } - return (u64)perf * mul / div; + + retval = offset + div64_u64(perf * mul, div); + if (retval >= 0) + return retval; + return 0; } static unsigned int cppc_cpufreq_khz_to_perf(struct cppc_cpudata *cpu, @@ -125,16 +124,13 @@ static unsigned int cppc_cpufreq_khz_to_perf(struct cppc_cpudata *cpu, { static u64 max_khz; struct cppc_perf_caps *caps = &cpu->perf_caps; + s64 retval, offset = 0; u64 mul, div; if (caps->lowest_freq && caps->nominal_freq) { - if (freq >= caps->nominal_freq) { - mul = caps->nominal_perf; - div = caps->nominal_freq; - } else { - mul = caps->lowest_perf; - div = caps->lowest_freq; - } + mul = caps->nominal_perf - caps->lowest_perf; + div = caps->nominal_freq - caps->lowest_freq; + offset = caps->nominal_perf - div64_u64(caps->nominal_freq * mul, div); } else { if (!max_khz) max_khz = cppc_get_dmi_max_khz(); @@ -142,7 +138,10 @@ static unsigned int cppc_cpufreq_khz_to_perf(struct cppc_cpudata *cpu, div = max_khz; } - return (u64)freq * mul / div; + retval = offset + div64_u64(freq * mul, div); + if (retval >= 0) + return retval; + return 0; } static int cppc_cpufreq_set_target(struct cpufreq_policy *policy, -- 2.25.1

2 1

[PATCH OLK-5.10] cpufreq: CPPC: Fix performance/frequency conversion
by Zeng Heng 23 Apr '24

23 Apr '24

From: Pierre Gondois <Pierre.Gondois(a)arm.com> mainline inclusion from mainline-v5.18-rc1 commit ec1c7ad47664f964c1101fe555b6fde0cb124b38 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8WAED Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- CPUfreq governors request CPU frequencies using information on current CPU usage. The CPPC driver converts them to performance requests. Frequency targets are computed as: target_freq = (util / cpu_capacity) * max_freq target_freq is then clamped between [policy->min, policy->max]. The CPPC driver converts performance values to frequencies (and vice-versa) using cppc_cpufreq_perf_to_khz() and cppc_cpufreq_khz_to_perf(). These functions both use two different factors depending on the range of the input value. For cppc_cpufreq_khz_to_perf(): - (NOMINAL_PERF / NOMINAL_FREQ) or - (LOWEST_PERF / LOWEST_FREQ) and for cppc_cpufreq_perf_to_khz(): - (NOMINAL_FREQ / NOMINAL_PERF) or - ((NOMINAL_PERF - LOWEST_FREQ) / (NOMINAL_PERF - LOWEST_PERF)) This means: 1- the functions are not inverse for some values: (perf_to_khz(khz_to_perf(x)) != x) 2- cppc_cpufreq_perf_to_khz(LOWEST_PERF) can sometimes give a different value from LOWEST_FREQ due to integer approximation 3- it is implied that performance and frequency are proportional (NOMINAL_FREQ / NOMINAL_PERF) == (LOWEST_PERF / LOWEST_FREQ) This patch changes the conversion functions to an affine function. This fixes the 3 points above. Suggested-by: Lukasz Luba <lukasz.luba(a)arm.com> Suggested-by: Morten Rasmussen <morten.rasmussen(a)arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois(a)arm.com> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/cpufreq/cppc_cpufreq.c | 43 +++++++++++++++++----------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index f7f3632dcf31..bb955318c024 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -89,35 +89,34 @@ static u64 cppc_get_dmi_max_khz(void) /* * If CPPC lowest_freq and nominal_freq registers are exposed then we can - * use them to convert perf to freq and vice versa - * - * If the perf/freq point lies between Nominal and Lowest, we can treat - * (Low perf, Low freq) and (Nom Perf, Nom freq) as 2D co-ordinates of a line - * and extrapolate the rest - * For perf/freq > Nominal, we use the ratio perf:freq at Nominal for conversion + * use them to convert perf to freq and vice versa. The conversion is + * extrapolated as an affine function passing by the 2 points: + * - (Low perf, Low freq) + * - (Nominal perf, Nominal perf) */ static unsigned int cppc_cpufreq_perf_to_khz(struct cppc_cpudata *cpu, unsigned int perf) { static u64 max_khz; struct cppc_perf_caps *caps = &cpu->perf_caps; + s64 retval, offset = 0; u64 mul, div; if (caps->lowest_freq && caps->nominal_freq) { - if (perf >= caps->nominal_perf) { - mul = caps->nominal_freq; - div = caps->nominal_perf; - } else { - mul = caps->nominal_freq - caps->lowest_freq; - div = caps->nominal_perf - caps->lowest_perf; - } + mul = caps->nominal_freq - caps->lowest_freq; + div = caps->nominal_perf - caps->lowest_perf; + offset = caps->nominal_freq - div64_u64(caps->nominal_perf * mul, div); } else { if (!max_khz) max_khz = cppc_get_dmi_max_khz(); mul = max_khz; div = caps->highest_perf; } - return (u64)perf * mul / div; + + retval = offset + div64_u64(perf * mul, div); + if (retval >= 0) + return retval; + return 0; } static unsigned int cppc_cpufreq_khz_to_perf(struct cppc_cpudata *cpu, @@ -125,16 +124,13 @@ static unsigned int cppc_cpufreq_khz_to_perf(struct cppc_cpudata *cpu, { static u64 max_khz; struct cppc_perf_caps *caps = &cpu->perf_caps; + s64 retval, offset = 0; u64 mul, div; if (caps->lowest_freq && caps->nominal_freq) { - if (freq >= caps->nominal_freq) { - mul = caps->nominal_perf; - div = caps->nominal_freq; - } else { - mul = caps->lowest_perf; - div = caps->lowest_freq; - } + mul = caps->nominal_perf - caps->lowest_perf; + div = caps->nominal_freq - caps->lowest_freq; + offset = caps->nominal_perf - div64_u64(caps->nominal_freq * mul, div); } else { if (!max_khz) max_khz = cppc_get_dmi_max_khz(); @@ -142,7 +138,10 @@ static unsigned int cppc_cpufreq_khz_to_perf(struct cppc_cpudata *cpu, div = max_khz; } - return (u64)freq * mul / div; + retval = offset + div64_u64(freq * mul, div); + if (retval >= 0) + return retval; + return 0; } static int cppc_cpufreq_set_target(struct cpufreq_policy *policy, -- 2.25.1

2 1

[PATCH OLK-6.6 v2] scsi: fnic: Move fnic_fnic_flush_tx() to a work queue
by Li Lingfeng 23 Apr '24

23 Apr '24

From: Lee Duncan <lduncan(a)suse.com> mainline inclusion from mainline-v6.8-rc5 commit 379a58caa19930e010b7efa1c1f3b9411d3d2ca3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HL6L CVE: CVE-2024-26917 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Rather than call 'fnic_flush_tx()' from interrupt context we should be moving it onto a work queue to avoid any locking issues. Fixes: 1a1975551943 ("scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock") Co-developed-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Lee Duncan <lduncan(a)suse.com> Link: https://lore.kernel.org/r/ce5ffa5d0ff82c2b2e283b3b4bff23291d49b05c.17075007… Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Conflict: drivers/scsi/fnic/fnic.h Commit 554a14826020 ("scsi: fnic: Refactor and redefine fnic.h for multiqueue") in mainline add copy_wq_base in fnic. Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- v1->v2: Change bugzilla to issue at gitee. drivers/scsi/fnic/fnic.h | 3 ++- drivers/scsi/fnic/fnic_fcs.c | 5 +++-- drivers/scsi/fnic/fnic_main.c | 1 + drivers/scsi/fnic/fnic_scsi.c | 4 ++-- 4 files changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h index 22cef283b2b9..dd1d248445d2 100644 --- a/drivers/scsi/fnic/fnic.h +++ b/drivers/scsi/fnic/fnic.h @@ -286,6 +286,7 @@ struct fnic { struct work_struct link_work; struct work_struct frame_work; + struct work_struct flush_work; struct sk_buff_head frame_queue; struct sk_buff_head tx_queue; @@ -341,7 +342,7 @@ void fnic_handle_event(struct work_struct *work); int fnic_rq_cmpl_handler(struct fnic *fnic, int); int fnic_alloc_rq_frame(struct vnic_rq *rq); void fnic_free_rq_buf(struct vnic_rq *rq, struct vnic_rq_buf *buf); -void fnic_flush_tx(struct fnic *); +void fnic_flush_tx(struct work_struct *work); void fnic_eth_send(struct fcoe_ctlr *, struct sk_buff *skb); void fnic_set_port_id(struct fc_lport *, u32, struct fc_frame *); void fnic_update_mac(struct fc_lport *, u8 *new); diff --git a/drivers/scsi/fnic/fnic_fcs.c b/drivers/scsi/fnic/fnic_fcs.c index 79ddfaaf71a4..daebe808579a 100644 --- a/drivers/scsi/fnic/fnic_fcs.c +++ b/drivers/scsi/fnic/fnic_fcs.c @@ -1174,7 +1174,7 @@ int fnic_send(struct fc_lport *lp, struct fc_frame *fp) /** * fnic_flush_tx() - send queued frames. - * @fnic: fnic device + * @work: pointer to work element * * Send frames that were waiting to go out in FC or Ethernet mode. * Whenever changing modes we purge queued frames, so these frames should @@ -1182,8 +1182,9 @@ int fnic_send(struct fc_lport *lp, struct fc_frame *fp) * * Called without fnic_lock held. */ -void fnic_flush_tx(struct fnic *fnic) +void fnic_flush_tx(struct work_struct *work) { + struct fnic *fnic = container_of(work, struct fnic, flush_work); struct sk_buff *skb; struct fc_frame *fp; diff --git a/drivers/scsi/fnic/fnic_main.c b/drivers/scsi/fnic/fnic_main.c index f27f9319e0b2..de369bb03e3e 100644 --- a/drivers/scsi/fnic/fnic_main.c +++ b/drivers/scsi/fnic/fnic_main.c @@ -792,6 +792,7 @@ static int fnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent) spin_lock_init(&fnic->vlans_lock); INIT_WORK(&fnic->fip_frame_work, fnic_handle_fip_frame); INIT_WORK(&fnic->event_work, fnic_handle_event); + INIT_WORK(&fnic->flush_work, fnic_flush_tx); skb_queue_head_init(&fnic->fip_frame_queue); INIT_LIST_HEAD(&fnic->evlist); INIT_LIST_HEAD(&fnic->vlans); diff --git a/drivers/scsi/fnic/fnic_scsi.c b/drivers/scsi/fnic/fnic_scsi.c index 416d81954819..d8b11880e19f 100644 --- a/drivers/scsi/fnic/fnic_scsi.c +++ b/drivers/scsi/fnic/fnic_scsi.c @@ -681,7 +681,7 @@ static int fnic_fcpio_fw_reset_cmpl_handler(struct fnic *fnic, spin_unlock_irqrestore(&fnic->fnic_lock, flags); - fnic_flush_tx(fnic); + queue_work(fnic_event_queue, &fnic->flush_work); reset_cmpl_handler_end: fnic_clear_state_flags(fnic, FNIC_FLAGS_FWRESET); @@ -737,7 +737,7 @@ static int fnic_fcpio_flogi_reg_cmpl_handler(struct fnic *fnic, } spin_unlock_irqrestore(&fnic->fnic_lock, flags); - fnic_flush_tx(fnic); + queue_work(fnic_event_queue, &fnic->flush_work); queue_work(fnic_event_queue, &fnic->frame_work); } else { spin_unlock_irqrestore(&fnic->fnic_lock, flags); -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] bpf: Fix hashtab overflow check on 32-bit arches
by Pu Lehui 23 Apr '24

23 Apr '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v4.19.311 commit 33ec04cadb77605b71d9298311919303d390c4d5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK6X CVE: CVE-2024-26884 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6787d916c2cf9850c97a0a3f73e08c43e7d973b1 ] The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup. Fixes: daaf427c6ab3 ("bpf: fix arraymap NULL deref and missing overflow and zero size checks") Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Message-ID: <20240307120340.99577-3-toke(a)redhat.com> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/hashtab.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 3f3ed33bd2fd..5d1310fc1441 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -330,7 +330,13 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr) num_possible_cpus()); } - /* hash table size must be power of 2 */ + /* hash table size must be power of 2; roundup_pow_of_two() can overflow + * into UB on 32-bit arches, so check that first + */ + err = -E2BIG; + if (htab->map.max_entries > 1UL << 31) + goto free_htab; + htab->n_buckets = roundup_pow_of_two(htab->map.max_entries); htab->elem_size = sizeof(struct htab_elem) + @@ -340,10 +346,8 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr) else htab->elem_size += round_up(htab->map.value_size, 8); - err = -E2BIG; - /* prevent zero size kmalloc and check for u32 overflow */ - if (htab->n_buckets == 0 || - htab->n_buckets > U32_MAX / sizeof(struct bucket)) + /* check for u32 overflow */ + if (htab->n_buckets > U32_MAX / sizeof(struct bucket)) goto free_htab; cost = (u64) htab->n_buckets * sizeof(struct bucket) + -- 2.34.1

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 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

[PATCH OLK-5.10 0/2] CVE-2021-47182
by Li Nan 23 Apr '24

23 Apr '24

Damien Le Moal (1): scsi: core: Fix scsi_mode_sense() buffer length handling Hannes Reinecke (1): scsi: core: Reshuffle response handling in scsi_mode_sense() drivers/scsi/scsi_lib.c | 94 +++++++++++++++++++++-------------------- 1 file changed, 49 insertions(+), 45 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS 0/3] CVE-2021-47182
by Li Nan 23 Apr '24

23 Apr '24

Damien Le Moal (1): scsi: core: Fix scsi_mode_sense() buffer length handling Hannes Reinecke (2): scsi: core: Fixup calling convention for scsi_mode_sense() scsi: core: Reshuffle response handling in scsi_mode_sense() drivers/scsi/scsi_lib.c | 100 ++++++++++++++++-------------- drivers/scsi/scsi_transport_sas.c | 9 ++- drivers/scsi/sd.c | 12 ++-- drivers/scsi/sr.c | 2 +- 4 files changed, 64 insertions(+), 59 deletions(-) -- 2.39.2

2 4

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

23 Apr '24

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 | 16 +++++++--------- include/linux/f2fs_fs.h | 1 + 7 files changed, 63 insertions(+), 42 deletions(-) -- 2.39.2

2 3

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

23 Apr '24

Fix CVE-2024-26869 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 | 14 ++++++-------- include/linux/f2fs_fs.h | 1 + 7 files changed, 62 insertions(+), 41 deletions(-) -- 2.39.2

2 3

[openeuler:OLK-5.10] BUILD REGRESSION b05f2de3edcf4fc1b98ced476a06a62b961d3cce
by kernel test robot 23 Apr '24

23 Apr '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: b05f2de3edcf4fc1b98ced476a06a62b961d3cce !6279 Bluetooth: Avoid potential use-after-free in hci_error_reset Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202404230205.XJi54qVa-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202404230552.HyMsovr7-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202404230626.ETmTJeuy-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) drivers/char/ipmi/ipmi_bt_sm.c:194:18: error: implicit declaration of function 'acpi_evaluate_integer'; did you mean 'acpi_evaluate_object'? [-Werror=implicit-function-declaration] drivers/ptp/ptp_hisi.c:731:36: warning: 'hisi_ptp_acpi_match' defined but not used [-Wunused-const-variable=] fs/proc/base.c:1454:6: warning: no previous prototype for 'pbha_bit0_hide_file' [-Wmissing-prototypes] Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- arm64-allnoconfig | |-- arch-arm64-kernel-ipi_nmi.c:error:implicit-declaration-of-function-printk_safe_enter | |-- arch-arm64-kernel-ipi_nmi.c:error:implicit-declaration-of-function-printk_safe_exit | |-- kernel-sched-core.c:error:implicit-declaration-of-function-init_auto_affinity | |-- kernel-sched-core.c:error:implicit-declaration-of-function-tg_update_affinity_domains | |-- kernel-sched-core.c:error:root_task_group-undeclared-(first-use-in-this-function) | |-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_enter | `-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_exit |-- arm64-randconfig-002-20240423 | |-- arch-arm64-kernel-ipi_nmi.c:error:implicit-declaration-of-function-printk_safe_enter | |-- arch-arm64-kernel-ipi_nmi.c:error:implicit-declaration-of-function-printk_safe_exit | |-- arch-arm64-kernel-vdso-ilp32-..-vdso-vgettimeofday.c:warning:no-previous-prototype-for-__kernel_clock_getres | |-- arch-arm64-kernel-vdso-ilp32-..-vdso-vgettimeofday.c:warning:no-previous-prototype-for-__kernel_clock_gettime | |-- arch-arm64-kernel-vdso-ilp32-..-vdso-vgettimeofday.c:warning:no-previous-prototype-for-__kernel_gettimeofday | |-- drivers-char-ipmi-ipmi_bt_sm.c:error:implicit-declaration-of-function-acpi_evaluate_integer | |-- drivers-ptp-ptp_hisi.c:warning:hisi_ptp_acpi_match-defined-but-not-used | |-- fs-proc-base.c:warning:no-previous-prototype-for-pbha_bit0_hide_file | |-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_enter | `-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_exit `-- x86_64-randconfig-076-20240422 |-- kernel-sched-core.c:error:implicit-declaration-of-function-init_auto_affinity |-- kernel-sched-core.c:error:implicit-declaration-of-function-tg_update_affinity_domains `-- kernel-sched-core.c:error:root_task_group-undeclared-(first-use-in-this-function) clang_recent_errors |-- arm64-allyesconfig | |-- Documentation-devicetree-bindings-arm-cpu.yaml:properties:capacity-dmips-mhz:ref-should-not-be-valid-under-const:ref | |-- Documentation-devicetree-bindings-arm-cpu.yaml:title:ARM-CPUs-bindings-should-not-be-valid-under-pattern:(-Bb-inding-Ss-chema) | |-- Documentation-devicetree-bindings-arm-cpus.yaml:examples:cpus-arm-pbha-performance-only-bits-arm-pbha-no-aliases-bits-ncpu-device_type-cpu-compatible-arm-cortex-a57-...-n-is-not-of-type-array | |-- Documentation-devicetree-bindings-arm-cpus.yaml:maintainers-is-a-required-property | |-- description:Display-controller-reference-clock-source-is-not-of-type-object-boolean | |-- description:Display-controller-reference-clock-source-is-too-short | |-- description:Offset-and-length-of-the-memory-mapped-registers-is-too-short | |-- items-is-not-one-of-type-description-dependencies-dependentRequired-dependentSchemas-properties-patternProperties-additionalProperties-unevaluatedProperties-deprecated-required-not-allOf-anyOf-oneOf-r | `-- minItems-is-not-one-of-type-description-dependencies-dependentRequired-dependentSchemas-properties-patternProperties-additionalProperties-unevaluatedProperties-deprecated-required-not-allOf-anyOf-oneO |-- x86_64-allnoconfig | `-- drivers-net-ethernet-mucse-rnpm-rnpm_common.h:linux-version.h-not-needed. `-- x86_64-allyesconfig |-- drivers-net-ethernet-bzwx-nce-comm-txrx.c:fatal-error:ne6x_trace.h-file-not-found |-- drivers-net-ethernet-bzwx-nce-ne6x-ne6x.h:fatal-error:reg.h-file-not-found `-- drivers-net-ethernet-bzwx-nce-ne6x_vf-ne6xvf.h:fatal-error:reg.h-file-not-found elapsed time: 727m configs tested: 35 configs skipped: 149 tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240423 clang arm64 randconfig-002-20240423 gcc arm64 randconfig-003-20240423 clang arm64 randconfig-004-20240423 clang x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240422 clang x86_64 buildonly-randconfig-002-20240422 gcc x86_64 buildonly-randconfig-003-20240422 gcc x86_64 buildonly-randconfig-004-20240422 clang x86_64 buildonly-randconfig-005-20240422 gcc x86_64 buildonly-randconfig-006-20240422 clang x86_64 defconfig gcc x86_64 randconfig-001-20240422 clang x86_64 randconfig-002-20240422 gcc x86_64 randconfig-003-20240422 clang x86_64 randconfig-004-20240422 gcc x86_64 randconfig-005-20240422 gcc x86_64 randconfig-006-20240422 clang x86_64 randconfig-011-20240422 gcc x86_64 randconfig-012-20240422 clang x86_64 randconfig-013-20240422 gcc x86_64 randconfig-014-20240422 clang x86_64 randconfig-015-20240422 gcc x86_64 randconfig-016-20240422 gcc x86_64 randconfig-071-20240422 clang x86_64 randconfig-072-20240422 gcc x86_64 randconfig-073-20240422 gcc x86_64 randconfig-074-20240422 gcc x86_64 randconfig-075-20240422 gcc x86_64 randconfig-076-20240422 gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6] BUILD REGRESSION e95a0071898084171841e9f3695a02fc5f58fd0f
by kernel test robot 23 Apr '24

23 Apr '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: e95a0071898084171841e9f3695a02fc5f58fd0f !6256 [OLK-6.6] bugfix from upstream v6.9 for AMD EPYC perf Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202404222001.4hDpVvmd-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202404230016.B1zZMDXC-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' reading between 65 and 536870912 bytes from a region of size 64 [-Wstringop-overread] ld.lld: error: undefined symbol: __memcpy_mc Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- arm64-allnoconfig | `-- arch-arm64-kernel-cpufeature.c:error:enable_pseudo_nmi-undeclared-(first-use-in-this-function) |-- arm64-randconfig-001-20240422 | `-- shadow.c:(.text):undefined-reference-to-__memcpy_mc |-- arm64-randconfig-003-20240422 | `-- include-linux-fortify-string.h:warning:__builtin_memcpy-reading-between-and-bytes-from-a-region-of-size |-- loongarch-allmodconfig | |-- drivers-net-ethernet-bzwx-nce-comm-txrx.c:fatal-error:ne6x_trace.h:No-such-file-or-directory | |-- drivers-net-ethernet-bzwx-nce-ne6x-ne6x.h:fatal-error:reg.h:No-such-file-or-directory | |-- drivers-net-ethernet-bzwx-nce-ne6x_vf-ne6xvf.h:fatal-error:reg.h:No-such-file-or-directory | |-- drivers-net-ethernet-mucse-rnp-rnp_main.c:warning:Function-parameter-or-member-netdev-not-described-in-rnp_netpoll | |-- drivers-net-ethernet-mucse-rnp-rnp_main.c:warning:expecting-prototype-for-Polling-interrupt-().-Prototype-was-for-rnp_netpoll()-instead | |-- drivers-net-ethernet-mucse-rnp-rnp_mbx_fw.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst | |-- drivers-net-ethernet-mucse-rnpvf-rnpvf_main.c:warning:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and | `-- drivers-net-ethernet-mucse-rnpvf-rnpvf_main.c:warning:no-previous-prototype-for-rnpvf_alloc_rx_buffers `-- loongarch-randconfig-002-20240422 |-- arch-loongarch-kvm-exit.c:error:struct-sched_info-has-no-member-named-run_delay `-- arch-loongarch-kvm-vcpu.c:error:struct-sched_info-has-no-member-named-run_delay clang_recent_errors |-- arm64-allmodconfig | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_init.c:warning:no-previous-prototype-for-function-sss_deinit_hwdev | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_init.c:warning:no-previous-prototype-for-function-sss_hwdev_detach | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_init.c:warning:no-previous-prototype-for-function-sss_hwdev_shutdown | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_init.c:warning:no-previous-prototype-for-function-sss_hwdev_stop | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_init.c:warning:no-previous-prototype-for-function-sss_init_hwdev | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_init.c:warning:variable-fault_level-set-but-not-used | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_init.c:warning:variable-pcie_src-set-but-not-used | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_io_flush.c:warning:no-previous-prototype-for-function-sss_hwdev_flush_io | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_mgmt_info.c:warning:no-previous-prototype-for-function-sss_deinit_mgmt_info | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwdev_mgmt_info.c:warning:no-previous-prototype-for-function-sss_init_mgmt_info | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm.c:warning:no-previous-prototype-for-function-sss_adm_msg_read | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm.c:warning:no-previous-prototype-for-function-sss_adm_msg_read_ack | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm.c:warning:no-previous-prototype-for-function-sss_adm_msg_write | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm.c:warning:no-previous-prototype-for-function-sss_adm_msg_write_nack | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm.c:warning:no-previous-prototype-for-function-sss_sync_send_adm_msg | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm_init.c:warning:no-previous-prototype-for-function-sss_complete_adm_event | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm_init.c:warning:no-previous-prototype-for-function-sss_destroy_adm_msg | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm_init.c:warning:no-previous-prototype-for-function-sss_hwif_deinit_adm | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_adm_init.c:warning:no-previous-prototype-for-function-sss_hwif_init_adm | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_ceq.c:warning:no-previous-prototype-for-function-sss_ceq_intr_handle | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_ceq.c:warning:no-previous-prototype-for-function-sss_init_ceqe_desc | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_ctrlq_init.c:warning:no-previous-prototype-for-function-sss_ctrlq_flush_sync_cmd | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_ctrlq_init.c:warning:no-previous-prototype-for-function-sss_deinit_ctrlq | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_ctrlq_init.c:warning:no-previous-prototype-for-function-sss_deinit_ctrlq_channel | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_ctrlq_init.c:warning:no-previous-prototype-for-function-sss_init_ctrlq_channel | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_ctrlq_init.c:warning:no-previous-prototype-for-function-sss_reinit_ctrlq_ctx | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_ctrlq_init.c:warning:no-previous-prototype-for-function-sss_wait_ctrlq_stop | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_alloc_db_addr | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_chip_set_msix_auto_mask | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_chip_set_msix_state | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_free_db_addr | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_get_func_id | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_get_func_type | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_get_glb_pf_vf_offset | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_get_global_func_id | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_get_pcie_itf_id | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_get_pf_id_of_vf | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_export.c:warning:no-previous-prototype-for-function-sss_get_ppf_id | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_irq.c:warning:no-previous-prototype-for-function-sss_deinit_irq_info | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_irq.c:warning:no-previous-prototype-for-function-sss_init_irq_info | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_mbx_init.c:warning:no-previous-prototype-for-function-sss_hwif_deinit_mbx | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_mbx_init.c:warning:no-previous-prototype-for-function-sss_hwif_init_mbx | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_mbx_init.c:warning:no-previous-prototype-for-function-sss_init_func_mbx_msg | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_mbx_init.c:warning:no-previous-prototype-for-function-sss_recv_mbx_aeq_handler | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_mgmt_init.c:warning:no-previous-prototype-for-function-sss_flush_mgmt_workq | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_mgmt_init.c:warning:no-previous-prototype-for-function-sss_force_complete_all | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_hwif_mgmt_init.c:warning:no-previous-prototype-for-function-sss_mgmt_msg_aeqe_handler | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_error.c:warning:no-previous-prototype-for-function-sss_detect_pci_error | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_global.c:warning:no-previous-prototype-for-function-sss_attach_is_enable | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_global.c:warning:no-previous-prototype-for-function-sss_get_uld_info | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_global.c:warning:no-previous-prototype-for-function-sss_get_uld_names | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_global.c:warning:no-previous-prototype-for-function-sss_init_uld_lock | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_global.c:warning:no-previous-prototype-for-function-sss_lock_uld | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_global.c:warning:no-previous-prototype-for-function-sss_unlock_uld | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_probe.c:warning:no-previous-prototype-for-function-sss_attach_uld_driver | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_probe.c:warning:no-previous-prototype-for-function-sss_pci_probe | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_remove.c:warning:no-previous-prototype-for-function-sss_deinit_adapter | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_remove.c:warning:no-previous-prototype-for-function-sss_deinit_function | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_remove.c:warning:no-previous-prototype-for-function-sss_deinit_pci_dev | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_remove.c:warning:no-previous-prototype-for-function-sss_detach_all_uld_driver | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_remove.c:warning:no-previous-prototype-for-function-sss_detach_uld_driver | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_remove.c:warning:no-previous-prototype-for-function-sss_dettach_uld_dev | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_remove.c:warning:no-previous-prototype-for-function-sss_pci_remove | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_remove.c:warning:no-previous-prototype-for-function-sss_unmap_pci_bar | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-sss_pci_shutdown.c:warning:no-previous-prototype-for-function-sss_pci_shutdown | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_chip.c:warning:no-previous-prototype-for-function-sss_tool_adm_csr_rd32 | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_chip.c:warning:no-previous-prototype-for-function-sss_tool_adm_csr_wr32 | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_chip.c:warning:no-previous-prototype-for-function-sss_tool_send_clp_msg | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_main.c:warning:no-previous-prototype-for-function-sss_tool_alloc_in_buf | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_main.c:warning:no-previous-prototype-for-function-sss_tool_alloc_out_buf | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_main.c:warning:no-previous-prototype-for-function-sss_tool_copy_to_user | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_main.c:warning:no-previous-prototype-for-function-sss_tool_free_in_buf | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_main.c:warning:no-previous-prototype-for-function-sss_tool_free_out_buf | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_sdk.c:warning:no-previous-prototype-for-function-sss_tool_get_func_id | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_sdk.c:warning:no-previous-prototype-for-function-sss_tool_get_func_type | |-- drivers-net-ethernet-3snic-sssnic-nic-..-hw-tool-sss_tool_sdk.c:warning:no-previous-prototype-for-function-sss_tool_get_hw_driver_stats | |-- drivers-net-ethernet-huawei-hinic-hinic_api_cmd.c:warning:expecting-prototype-for-prepare_cell().-Prototype-was-for-wait_for_resp_polling()-instead | |-- drivers-net-ethernet-huawei-hinic-hinic_cfg.c:warning:arithmetic-between-different-enumeration-types-(-enum-hinic_node_id-and-enum-hinic_fault_err_level-) | |-- drivers-net-ethernet-huawei-hinic-hinic_eqs.c:warning:expecting-prototype-for-hinic_aeq_register_sw_cb().-Prototype-was-for-hinic_aeq_register_swe_cb()-instead | |-- drivers-net-ethernet-huawei-hinic-hinic_eqs.c:warning:expecting-prototype-for-hinic_aeq_unregister_sw_cb().-Prototype-was-for-hinic_aeq_unregister_swe_cb()-instead | |-- drivers-net-ethernet-huawei-hinic-hinic_eqs.c:warning:expecting-prototype-for-hinic_ceq_register_sw_cb().-Prototype-was-for-hinic_ceq_register_cb()-instead | |-- drivers-net-ethernet-huawei-hinic-hinic_hwdev.c:warning:arithmetic-between-different-enumeration-types-(-enum-hinic_node_id-and-enum-hinic_fault_err_level-) | |-- drivers-net-ethernet-huawei-hinic-hinic_hwif.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst | |-- drivers-net-ethernet-huawei-hinic-hinic_mbox.c:warning:expecting-prototype-for-hinic_unregister_ppf_mbox_cb().-Prototype-was-for-hinic_unregister_pf_mbox_cb()-instead | |-- drivers-net-ethernet-huawei-hinic-hinic_mbox.c:warning:expecting-prototype-for-hinic_unregister_ppf_mbox_cb().-Prototype-was-for-hinic_unregister_ppf_to_pf_mbox_cb()-instead | |-- drivers-net-ethernet-huawei-hinic-hinic_mgmt.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst | |-- drivers-net-ethernet-huawei-hinic-hinic_nic_dbg.c:warning:arithmetic-between-different-enumeration-types-(-enum-hinic_node_id-and-enum-hinic_fault_err_level-) | |-- drivers-net-ethernet-huawei-hinic3-hw-hinic3_api_cmd.c:warning:expecting-prototype-for-alloc_cmd_buf().-Prototype-was-for-alloc_resp_buf()-instead | |-- drivers-net-ethernet-huawei-hinic3-hw-hinic3_api_cmd.c:warning:expecting-prototype-for-prepare_cell().-Prototype-was-for-wait_for_resp_polling()-instead | |-- drivers-net-ethernet-huawei-hinic3-hw-hinic3_devlink.c:warning:variable-pdev-set-but-not-used | |-- drivers-net-ethernet-huawei-hinic3-hw-hinic3_mbox.c:warning:expecting-prototype-for-hinic3_unregister_ppf_mbox_cb().-Prototype-was-for-hinic3_unregister_pf_mbox_cb()-instead | |-- drivers-net-ethernet-huawei-hinic3-hw-hinic3_mbox.c:warning:expecting-prototype-for-hinic3_unregister_ppf_mbox_cb().-Prototype-was-for-hinic3_unregister_ppf_to_pf_mbox_cb()-instead | |-- drivers-net-ethernet-huawei-hinic3-hw-hinic3_mgmt.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst | |-- drivers-net-ethernet-huawei-hinic3-hw-hinic3_mgmt.c:warning:expecting-prototype-for-hinic_pf_to_mgmt_free().-Prototype-was-for-hinic3_pf_to_mgmt_free()-instead | |-- drivers-net-ethernet-huawei-hinic3-hw-hinic3_mgmt.c:warning:expecting-prototype-for-hinic_pf_to_mgmt_init().-Prototype-was-for-hinic3_pf_to_mgmt_init()-instead | |-- drivers-net-ethernet-mucse-rnp-rnp_main.c:warning:Function-parameter-or-member-netdev-not-described-in-rnp_netpoll | |-- drivers-net-ethernet-mucse-rnp-rnp_main.c:warning:expecting-prototype-for-Polling-interrupt-().-Prototype-was-for-rnp_netpoll()-instead | |-- drivers-net-ethernet-mucse-rnp-rnp_mbx_fw.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst | |-- drivers-scsi-hisi_raid-hiraid_main.c:warning:expecting-prototype-for-hiraid_create_cq().-Prototype-was-for-hiraid_create_complete_queue()-instead | `-- drivers-scsi-hisi_raid-hiraid_main.c:warning:expecting-prototype-for-hiraid_create_sq().-Prototype-was-for-hiraid_create_send_queue()-instead `-- arm64-randconfig-002-20240422 `-- ld.lld:error:undefined-symbol:__memcpy_mc elapsed time: 725m configs tested: 40 configs skipped: 143 tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240422 gcc arm64 randconfig-002-20240422 clang arm64 randconfig-003-20240422 gcc arm64 randconfig-004-20240422 gcc loongarch allmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc loongarch randconfig-001-20240422 gcc loongarch randconfig-002-20240422 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240422 clang x86_64 buildonly-randconfig-002-20240422 gcc x86_64 buildonly-randconfig-003-20240422 gcc x86_64 buildonly-randconfig-004-20240422 clang x86_64 buildonly-randconfig-005-20240422 gcc x86_64 buildonly-randconfig-006-20240422 clang x86_64 defconfig gcc x86_64 randconfig-001-20240422 clang x86_64 randconfig-002-20240422 gcc x86_64 randconfig-003-20240422 clang x86_64 randconfig-004-20240422 gcc x86_64 randconfig-005-20240422 gcc x86_64 randconfig-006-20240422 clang x86_64 randconfig-011-20240422 gcc x86_64 randconfig-012-20240422 clang x86_64 randconfig-013-20240422 gcc x86_64 randconfig-014-20240422 clang x86_64 randconfig-015-20240422 gcc x86_64 randconfig-016-20240422 gcc x86_64 randconfig-071-20240422 clang x86_64 randconfig-072-20240422 gcc x86_64 randconfig-073-20240422 gcc x86_64 randconfig-074-20240422 gcc x86_64 randconfig-075-20240422 gcc x86_64 randconfig-076-20240422 gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 28936/30000] fs/proc/base.c:1454:6: warning: no previous prototype for 'pbha_bit0_hide_file'
by kernel test robot 23 Apr '24

23 Apr '24

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: b05f2de3edcf4fc1b98ced476a06a62b961d3cce commit: bea38841945a52bd03004240eb0da6a5115bae21 [28936/30000] arm64: mm: Hide pbha_bit0 in procfs if pbha is not enabled config: arm64-randconfig-002-20240423 (https://download.01.org/0day-ci/archive/20240423/202404230626.ETmTJeuy-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240423/202404230626.ETmTJeuy-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/202404230626.ETmTJeuy-lkp@intel.com/ All warnings (new ones prefixed by >>): >> fs/proc/base.c:1454:6: warning: no previous prototype for 'pbha_bit0_hide_file' [-Wmissing-prototypes] 1454 | bool pbha_bit0_hide_file(const char *name) | ^~~~~~~~~~~~~~~~~~~ vim +/pbha_bit0_hide_file +1454 fs/proc/base.c 1453 > 1454 bool pbha_bit0_hide_file(const char *name) 1455 { 1456 if (!system_support_pbha_bit0() && !strncmp("pbha_bit0", name, 9)) 1457 return true; 1458 1459 return false; 1460 } 1461 #else 1462 static bool pbha_bit0_hide_file(const char *name) { return false; } 1463 #endif 1464 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS] BUILD REGRESSION aaa8e73e6e85e82e5b0425d2039e1cbc57089fea
by kernel test robot 23 Apr '24

23 Apr '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: aaa8e73e6e85e82e5b0425d2039e1cbc57089fea !6203 ALSA: usb-audio: fix null pointer dereference on pointer cs_desc Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202404222359.bREYOZA3-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202404230151.AOKJ44d0-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) drivers/edac/.tmp_i10nm_base.o: warning: objtool: missing symbol for section .exit.text drivers/edac/.tmp_skx_base.o: warning: objtool: missing symbol for section .exit.text Unverified Error/Warning (likely false positive, please contact us if interested): arch/x86/kernel/cpu/mce/therm_throt.c:366:13: sparse: sparse: cast removes address space '<asn:3>' of expression Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- x86_64-buildonly-randconfig-002-20240422 | `-- arch-x86-include-asm-paravirt.h:warning:mcu_ctrl-may-be-used-uninitialized |-- x86_64-buildonly-randconfig-003-20240422 | |-- drivers-edac-.tmp_i10nm_base.o:warning:objtool:missing-symbol-for-section-.exit.text | `-- drivers-edac-.tmp_skx_base.o:warning:objtool:missing-symbol-for-section-.exit.text |-- x86_64-buildonly-randconfig-005-20240422 | |-- include-linux-list.h:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node | |-- include-linux-plist.h:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node | `-- mm-swapfile.c:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node `-- x86_64-randconfig-122-20240423 |-- arch-x86-kernel-cpu-mce-therm_throt.c:sparse:sparse:cast-removes-address-space-asn-of-expression |-- drivers-md-bcache-request.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-const-noderef-asn-from-got-struct-set_bcache_status |-- drivers-md-bcache-request.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-to-got-struct-get_bcache_status |-- drivers-pci-controller-hisi-pcie-customer-hisi_pcie_cae.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-to-got-void |-- drivers-pci-rom.c:sparse:sparse:incorrect-type-in-return-expression-(different-address-spaces)-expected-void-noderef-asn-got-void |-- fs-io_uring.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-long-long-noderef-usertype-asn-off_in-got-long-long-usertype-assigned-poff_in |-- fs-io_uring.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-long-long-noderef-usertype-asn-off_out-got-long-long-usertype-assigned-poff_out |-- fs-io_uring.c:sparse:sparse:incorrect-type-in-assignment-(different-address-spaces)-expected-struct-file-assigned-file-got-struct-file-noderef-asn |-- fs-io_uring.c:sparse:sparse:incorrect-type-in-return-expression-(different-address-spaces)-expected-void-noderef-asn-got-struct-io_buffer-assigned-kbuf |-- include-linux-compiler.h:warning:array-subscript-index-is-outside-array-bounds-of-u32-aka-unsigned-int |-- include-linux-compiler.h:warning:array-subscript-unknown-is-outside-array-bounds-of-const-u32-aka-const-unsigned-int |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-got-int-noderef-pmu_disable_count |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-got-struct-perf_cpu_context-noderef-pmu_cpu_context |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-void-const-noderef-asn-got-int |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-void-const-noderef-asn-got-struct-perf_cpu_context `-- net-ipv4-arp.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-type-sizes): clang_recent_errors |-- x86_64-buildonly-randconfig-006-20240422 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-001-20240422 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-003-20240422 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-006-20240422 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-012-20240422 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-014-20240422 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-071-20240422 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-121-20240423 | |-- drivers-gpu-drm-nouveau-nouveau_fence.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-struct-nouveau_channel-chan-got-struct-nouveau_channel-noderef-asn-channel | |-- drivers-gpu-drm-radeon-radeon_bios.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-const-src-got-unsigned-char-noderef-usertype-asn-assigned-bios | |-- drivers-pci-controller-hisi-pcie-customer-hisi_pcie_cae.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-to-got-void | |-- drivers-pci-rom.c:sparse:sparse:incorrect-type-in-return-expression-(different-address-spaces)-expected-void-noderef-asn-got-void | |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-got-int-noderef-pmu_disable_count | |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-got-struct-perf_cpu_context-noderef-pmu_cpu_context | |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-void-const-noderef-asn-got-int | |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-void-const-noderef-asn-got-struct-perf_cpu_context | |-- net-ipv4-arp.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-type-sizes): | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) `-- x86_64-randconfig-123-20240423 |-- drivers-pci-controller-hisi-pcie-customer-hisi_pcie_cae.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-to-got-void |-- drivers-pci-rom.c:sparse:sparse:incorrect-type-in-return-expression-(different-address-spaces)-expected-void-noderef-asn-got-void |-- fs-io_uring.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-long-long-noderef-usertype-asn-off_in-got-long-long-usertype-assigned-poff_in |-- fs-io_uring.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-long-long-noderef-usertype-asn-off_out-got-long-long-usertype-assigned-poff_out |-- fs-io_uring.c:sparse:sparse:incorrect-type-in-assignment-(different-address-spaces)-expected-struct-file-assigned-file-got-struct-file-noderef-asn |-- fs-io_uring.c:sparse:sparse:incorrect-type-in-return-expression-(different-address-spaces)-expected-void-noderef-asn-got-struct-io_buffer-assigned-kbuf |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-got-int-noderef-pmu_disable_count |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-void-noderef-asn-got-struct-perf_cpu_context-noderef-pmu_cpu_context |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-void-const-noderef-asn-got-int |-- kernel-events-core.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-void-const-noderef-asn-got-struct-perf_cpu_context |-- net-ipv4-arp.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-type-sizes): `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) elapsed time: 726m configs tested: 34 configs skipped: 148 tested configs: arm64 allmodconfig gcc arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240422 gcc arm64 randconfig-003-20240422 gcc arm64 randconfig-004-20240422 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240422 clang x86_64 buildonly-randconfig-002-20240422 gcc x86_64 buildonly-randconfig-003-20240422 gcc x86_64 buildonly-randconfig-004-20240422 clang x86_64 buildonly-randconfig-005-20240422 gcc x86_64 buildonly-randconfig-006-20240422 clang x86_64 defconfig gcc x86_64 randconfig-001-20240422 clang x86_64 randconfig-002-20240422 gcc x86_64 randconfig-003-20240422 clang x86_64 randconfig-004-20240422 gcc x86_64 randconfig-005-20240422 gcc x86_64 randconfig-006-20240422 clang x86_64 randconfig-011-20240422 gcc x86_64 randconfig-012-20240422 clang x86_64 randconfig-013-20240422 gcc x86_64 randconfig-014-20240422 clang x86_64 randconfig-015-20240422 gcc x86_64 randconfig-016-20240422 gcc x86_64 randconfig-071-20240422 clang x86_64 randconfig-072-20240422 gcc x86_64 randconfig-073-20240422 gcc x86_64 randconfig-074-20240422 gcc x86_64 randconfig-075-20240422 gcc x86_64 randconfig-076-20240422 gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 24732/30000] drivers/char/ipmi/ipmi_bt_sm.c:194:18: error: implicit declaration of function 'acpi_evaluate_integer'; did you mean 'acpi_evaluate_object'?
by kernel test robot 23 Apr '24

23 Apr '24

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: b05f2de3edcf4fc1b98ced476a06a62b961d3cce commit: c1d32ce403f2c2b53138bfdba94c67cad8d137fd [24732/30000] ipmi: Errata workaround to prevent SMS message processing timeout config: arm64-randconfig-002-20240423 (https://download.01.org/0day-ci/archive/20240423/202404230552.HyMsovr7-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240423/202404230552.HyMsovr7-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/202404230552.HyMsovr7-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/char/ipmi/ipmi_bt_sm.c: In function 'get_sms_atn_quirk': >> drivers/char/ipmi/ipmi_bt_sm.c:194:18: error: implicit declaration of function 'acpi_evaluate_integer'; did you mean 'acpi_evaluate_object'? [-Werror=implicit-function-declaration] 194 | status = acpi_evaluate_integer(handle, "SATN", NULL, &tmp); | ^~~~~~~~~~~~~~~~~~~~~ | acpi_evaluate_object cc1: some warnings being treated as errors vim +194 drivers/char/ipmi/ipmi_bt_sm.c 177 178 #ifdef CONFIG_HISILICON_ERRATUM_162102203 179 /* 180 * To confirm whether the SMS_ATN flag needs to be stored and get 181 * quirk through the method reported by the BIOS. Because in special 182 * cases SMS_ATN flag bits may be lost before being processed. 183 */ 184 static bool get_sms_atn_quirk(struct si_sm_io *io) 185 { 186 acpi_handle handle; 187 acpi_status status; 188 unsigned long long tmp; 189 190 handle = ACPI_HANDLE(io->dev); 191 if (!handle) 192 return false; 193 > 194 status = acpi_evaluate_integer(handle, "SATN", NULL, &tmp); 195 if (ACPI_FAILURE(status)) 196 return false; 197 else if (tmp != 1) 198 return false; 199 200 return true; 201 } 202 #endif 203 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 20368/30000] drivers/ptp/ptp_hisi.c:731:36: warning: 'hisi_ptp_acpi_match' defined but not used
by kernel test robot 23 Apr '24

23 Apr '24

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: b05f2de3edcf4fc1b98ced476a06a62b961d3cce commit: c64545e1e5fa4e09603149e918f306562a22a60a [20368/30000] net: hns3: add support for Hisilicon ptp sync device config: arm64-randconfig-002-20240423 (https://download.01.org/0day-ci/archive/20240423/202404230205.XJi54qVa-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240423/202404230205.XJi54qVa-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/202404230205.XJi54qVa-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/ptp/ptp_hisi.c:731:36: warning: 'hisi_ptp_acpi_match' defined but not used [-Wunused-const-variable=] 731 | static const struct acpi_device_id hisi_ptp_acpi_match[] = { | ^~~~~~~~~~~~~~~~~~~ vim +/hisi_ptp_acpi_match +731 drivers/ptp/ptp_hisi.c 730 > 731 static const struct acpi_device_id hisi_ptp_acpi_match[] = { 732 { "HISI0411", 0 }, 733 { } 734 }; 735 MODULE_DEVICE_TABLE(acpi, hisi_ptp_acpi_match); 736 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0