CVSS: 7.0EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41058 – cachefiles: fix slab-use-after-free in fscache_withdraw_volume()
https://notcve.org/view.php?id=CVE-2024-41058
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in fscache_withdraw_volume() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370 Read of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798 CPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565 Call Trace: kasan_check_range+0xf6/0x1b0 fscache_withdraw_volume+0x2e1/0x370 cachefiles_withdraw_volume+0x31/0x50 cachefiles_withdraw_cache+0x3ad/0x900 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 Allocated by task 5820: __kmalloc+0x1df/0x4b0 fscache_alloc_volume+0x70/0x600 __fscache_acquire_volume+0x1c/0x610 erofs_fscache_register_volume+0x96/0x1a0 erofs_fscache_register_fs+0x49a/0x690 erofs_fc_fill_super+0x6c0/0xcc0 vfs_get_super+0xa9/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 [...] Freed by task 5820: kfree+0xf1/0x2c0 fscache_put_volume.part.0+0x5cb/0x9e0 erofs_fscache_unregister_fs+0x157/0x1b0 erofs_kill_sb+0xd9/0x1c0 deactivate_locked_super+0xa3/0x100 vfs_get_super+0x105/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 [...] ================================================================== Following is the process that triggers the issue: mount failed | daemon exit ------------------------------------------------------------ deactivate_locked_super cachefiles_daemon_release erofs_kill_sb erofs_fscache_unregister_fs fscache_relinquish_volume __fscache_relinquish_volume fscache_put_volume(fscache_volume, fscache_volume_put_relinquish) zero = __refcount_dec_and_test(&fscache_volume->ref, &ref); cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache cachefiles_withdraw_volumes list_del_init(&volume->cache_link) fscache_free_volume(fscache_volume) cache->ops->free_volume cachefiles_free_volume list_del_init(&cachefiles_volume->cache_link); kfree(fscache_volume) cachefiles_withdraw_volume fscache_withdraw_volume fscache_volume->n_accesses // fscache_volume UAF !!! The fscache_volume in cache->volumes must not have been freed yet, but its reference count may be 0. So use the new fscache_try_get_volume() helper function try to get its reference count. If the reference count of fscache_volume is 0, fscache_put_volume() is freeing it, so wait for it to be removed from cache->volumes. If its reference count is not 0, call cachefiles_withdraw_volume() with reference count protection to avoid the above issue. • https://git.kernel.org/stable/c/fe2140e2f57fef8562e0f9b7cd447d2b08dc2f35 https://git.kernel.org/stable/c/90f17e47f1e209c6a3c92a1d038a0a80c95c460e https://git.kernel.org/stable/c/9dd7f5663899ea13a6a73216106d9c13c37453e3 https://git.kernel.org/stable/c/38b88d544216f806d93a273a62ff8ebe82254003 https://git.kernel.org/stable/c/522018a0de6b6fcce60c04f86dfc5f0e4b6a1b36 https://access.redhat.com/security/cve/CVE-2024-41058 https://bugzilla.redhat.com/show_bug.cgi?id=2300432 • CWE-416: Use After Free •
CVSS: 7.0EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41057 – cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()
https://notcve.org/view.php?id=CVE-2024-41057
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600 Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109 CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566 Call Trace: <TASK> kasan_report+0x93/0xc0 cachefiles_withdraw_cookie+0x4d9/0x600 fscache_cookie_state_machine+0x5c8/0x1230 fscache_cookie_worker+0x91/0x1c0 process_one_work+0x7fa/0x1800 [...] Allocated by task 117: kmalloc_trace+0x1b3/0x3c0 cachefiles_acquire_volume+0xf3/0x9c0 fscache_create_volume_work+0x97/0x150 process_one_work+0x7fa/0x1800 [...] Freed by task 120301: kfree+0xf1/0x2c0 cachefiles_withdraw_cache+0x3fa/0x920 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 do_exit+0x87a/0x29b0 [...] ================================================================== Following is the process that triggers the issue: p1 | p2 ------------------------------------------------------------ fscache_begin_lookup fscache_begin_volume_access fscache_cache_is_live(fscache_cache) cachefiles_daemon_release cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache fscache_withdraw_cache fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN); cachefiles_withdraw_objects(cache) fscache_wait_for_objects(fscache) atomic_read(&fscache_cache->object_count) == 0 fscache_perform_lookup cachefiles_lookup_cookie cachefiles_alloc_object refcount_set(&object->ref, 1); object->volume = volume fscache_count_object(vcookie->cache); atomic_inc(&fscache_cache->object_count) cachefiles_withdraw_volumes cachefiles_withdraw_volume fscache_withdraw_volume __cachefiles_free_volume kfree(cachefiles_volume) fscache_cookie_state_machine cachefiles_withdraw_cookie cache = object->volume->cache; // cachefiles_volume UAF !!! After setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups to complete first, and then wait for fscache_cache->object_count == 0 to avoid the cookie exiting after the volume has been freed and triggering the above issue. Therefore call fscache_withdraw_volume() before calling cachefiles_withdraw_objects(). This way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two cases will occur: 1) fscache_begin_lookup fails in fscache_begin_volume_access(). 2) fscache_withdraw_volume() will ensure that fscache_count_object() has been executed before calling fscache_wait_for_objects(). • https://git.kernel.org/stable/c/fe2140e2f57fef8562e0f9b7cd447d2b08dc2f35 https://git.kernel.org/stable/c/8de253177112a47c9af157d23ae934779188b4e1 https://git.kernel.org/stable/c/9e67589a4a7b7e5660b524d1d5fe61242bcbcc11 https://git.kernel.org/stable/c/ef81340401e8a371d6b17f69e76d861920972cfe https://git.kernel.org/stable/c/5d8f805789072ea7fd39504694b7bd17e5f751c4 https://access.redhat.com/security/cve/CVE-2024-41057 https://bugzilla.redhat.com/show_bug.cgi?id=2300431 • CWE-416: Use After Free •
CVSS: 5.2EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41056 – firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files
https://notcve.org/view.php?id=CVE-2024-41056
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files. In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing. • https://git.kernel.org/stable/c/f6bc909e7673c30abcbdb329e7d0aa2e83c103d7 https://git.kernel.org/stable/c/16d76857d6b5426f41b587d0bb925de3f25bfb21 https://git.kernel.org/stable/c/392cff2f86a25a4286ff3151c7739143c61c1781 https://git.kernel.org/stable/c/53a9f8cdbf35a682e9894e1a606f4640e5359185 https://git.kernel.org/stable/c/680e126ec0400f6daecf0510c5bb97a55779ff03 https://access.redhat.com/security/cve/CVE-2024-41056 https://bugzilla.redhat.com/show_bug.cgi?id=2300430 • CWE-787: Out-of-bounds Write •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41055 – mm: prevent derefencing NULL ptr in pfn_section_valid()
https://notcve.org/view.php?id=CVE-2024-41055
In the Linux kernel, the following vulnerability has been resolved: mm: prevent derefencing NULL ptr in pfn_section_valid() Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage") changed pfn_section_valid() to add a READ_ONCE() call around "ms->usage" to fix a race with section_deactivate() where ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it. • https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529 https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97 https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800 https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7 https://git.kernel.org/stable/c/0100aeb8a12d51950418e685f879cc80cb8e5982 https://git.kernel.org/stable/c/bc17f2377818dca643a74499c3f533350 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-41054 – scsi: ufs: core: Fix ufshcd_clear_cmd racing issue
https://notcve.org/view.php?id=CVE-2024-41054
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix ufshcd_clear_cmd racing issue When ufshcd_clear_cmd is racing with the completion ISR, the completed tag of the request's mq_hctx pointer will be set to NULL by the ISR. And ufshcd_clear_cmd's call to ufshcd_mcq_req_to_hwq will get NULL pointer KE. Return success when the request is completed by ISR because sq does not need cleanup. The racing flow is: Thread A ufshcd_err_handler step 1 ufshcd_try_to_abort_task ufshcd_cmd_inflight(true) step 3 ufshcd_clear_cmd ... ufshcd_mcq_req_to_hwq blk_mq_unique_tag rq->mq_hctx->queue_num step 5 Thread B ufs_mtk_mcq_intr(cq complete ISR) step 2 scsi_done ... __blk_mq_free_request rq->mq_hctx = NULL; step 4 Below is KE back trace: ufshcd_try_to_abort_task: cmd pending in the device. tag = 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194 pc : [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14 lr : [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc [ufs_mediatek_mod_ise] Workqueue: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise] Call trace: dump_backtrace+0xf8/0x148 show_stack+0x18/0x24 dump_stack_lvl+0x60/0x7c dump_stack+0x18/0x3c mrdump_common_die+0x24c/0x398 [mrdump] ipanic_die+0x20/0x34 [mrdump] notify_die+0x80/0xd8 die+0x94/0x2b8 __do_kernel_fault+0x264/0x298 do_page_fault+0xa4/0x4b8 do_translation_fault+0x38/0x54 do_mem_abort+0x58/0x118 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x54/0x90 el1h_64_sync+0x68/0x6c blk_mq_unique_tag+0x8/0x14 ufshcd_clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise] ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise] ufshcd_err_handler+0xa7c/0xfa8 [ufs_mediatek_mod_ise] process_one_work+0x208/0x4fc worker_thread+0x228/0x438 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20 • https://git.kernel.org/stable/c/8d7290348992f27242dd6a696fa2eede709f0b14 https://git.kernel.org/stable/c/bed0896008334eeee4b4bfd7150491ca098cbf72 https://git.kernel.org/stable/c/11d81233f4ebe6907b12c79ad7d8787aa4db0633 https://git.kernel.org/stable/c/9307a998cb9846a2557fdca286997430bee36a2a •