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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-41053 – scsi: ufs: core: Fix ufshcd_abort_one racing issue
https://notcve.org/view.php?id=CVE-2024-41053
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix ufshcd_abort_one racing issue When ufshcd_abort_one is racing with the completion ISR, the completed tag of the request's mq_hctx pointer will be set to NULL by ISR. Return success when request is completed by ISR because ufshcd_abort_one does not need to do anything. The racing flow is: Thread A ufshcd_err_handler step 1 ... ufshcd_abort_one ufshcd_try_to_abort_task ufshcd_cmd_inflight(true) step 3 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 at tag 41 not pending in the device. ufshcd_try_to_abort_task: cmd at tag=41 is cleared. Aborting tag 41 / CDB 0x28 succeeded Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194 pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14 lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40 [ufs_mediatek_mod_ise] 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_err_handler+0xae4/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/ff7699d3620763b0dfe2ff93df4528880bf903a8 https://git.kernel.org/stable/c/93e6c0e19d5bb12b49534a411c85e21d333731fa https://git.kernel.org/stable/c/c3111b3cf3889bfa7b73ebff83d7397db9b7e5e0 https://git.kernel.org/stable/c/b5a6ac887256762758bfe7f2918cb0233aa544f4 https://git.kernel.org/stable/c/74736103fb4123c71bf11fb7a6abe7c884c5269e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41052 – vfio/pci: Init the count variable in collecting hot-reset devices
https://notcve.org/view.php?id=CVE-2024-41052
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Init the count variable in collecting hot-reset devices The count variable is used without initialization, it results in mistakes in the device counting and crashes the userspace if the get hot reset info path is triggered. • https://git.kernel.org/stable/c/618fbf4c910a06a3aa6a8b88a5fb1f2197f964f3 https://git.kernel.org/stable/c/9313244c26f3792daa86f3a18cc3bd5ad60310e0 https://git.kernel.org/stable/c/f476dffc52ea70745dcabf63288e770e50ac9ab3 https://git.kernel.org/stable/c/f44136b9652291ac1fc39ca67c053ac624d0d11b https://git.kernel.org/stable/c/5a88a3f67e37e39f933b38ebb4985ba5822e9eca •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41051 – cachefiles: wait for ondemand_object_worker to finish when dropping object
https://notcve.org/view.php?id=CVE-2024-41051
In the Linux kernel, the following vulnerability has been resolved: cachefiles: wait for ondemand_object_worker to finish when dropping object When queuing ondemand_object_worker() to re-open the object, cachefiles_object is not pinned. The cachefiles_object may be freed when the pending read request is completed intentionally and the related erofs is umounted. If ondemand_object_worker() runs after the object is freed, it will incur use-after-free problem as shown below. process A processs B process C process D cachefiles_ondemand_send_req() // send a read req X // wait for its completion // close ondemand fd cachefiles_ondemand_fd_release() // set object as CLOSE cachefiles_ondemand_daemon_read() // set object as REOPENING queue_work(fscache_wq, &info->ondemand_work) // close /dev/cachefiles cachefiles_daemon_release cachefiles_flush_reqs complete(&req->done) // read req X is completed // umount the erofs fs cachefiles_put_object() // object will be freed cachefiles_ondemand_deinit_obj_info() kmem_cache_free(object) // both info and object are freed ondemand_object_worker() When dropping an object, it is no longer necessary to reopen the object, so use cancel_work_sync() to cancel or wait for ondemand_object_worker() to finish. • https://git.kernel.org/stable/c/f17443d52d805c9a7fab5e67a4e8b973626fe1cd https://git.kernel.org/stable/c/f740fd943bb1fbf79b7eaba3c71eb7536f437f51 https://git.kernel.org/stable/c/0a7e54c1959c0feb2de23397ec09c7692364313e https://git.kernel.org/stable/c/ec9289369259d982e735a71437e32e6b4035290c https://git.kernel.org/stable/c/d3179bae72b1b5e555ba839d6d9f40a350a4d78a https://git.kernel.org/stable/c/b26525b2183632f16a3a4108fe6a4bfa8afac6ed https://git.kernel.org/stable/c/12e009d60852f7bce0afc373ca0b320f14150418 •