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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41050 – cachefiles: cyclic allocation of msg_id to avoid reuse
https://notcve.org/view.php?id=CVE-2024-41050
In the Linux kernel, the following vulnerability has been resolved: cachefiles: cyclic allocation of msg_id to avoid reuse Reusing the msg_id after a maliciously completed reopen request may cause a read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3 ------------------------------------------------- cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // get msg_id 6 wait_for_completion(&req_A->done) cachefiles_ondemand_daemon_read // read msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Malicious completion msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // will not set the object to close // because ondemand_id && fd is valid. // ondemand_object_worker() is done // but the object is still reopening. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reuse msg_id 6 process_open_req copen 6,A.size // The expected failed copen was executed successfully Expect copen to fail, and when it does, it closes fd, which sets the object to close, and then close triggers reopen again. However, due to msg_id reuse resulting in a successful copen, the anonymous fd is not closed until the daemon exits. Therefore read requests waiting for reopen to complete may trigger hung task. To avoid this issue, allocate the msg_id cyclically to avoid reusing the msg_id for a very short duration of time. • https://git.kernel.org/stable/c/c8383054506c77b814489c09877b5db83fd4abf2 https://git.kernel.org/stable/c/35710c6c4a1c64478ec1b5e0e81d386c0844dec6 https://git.kernel.org/stable/c/de045a82e1a4e04be62718d3c2981a55150765a0 https://git.kernel.org/stable/c/9d3bf4e9aa23f0d9e99ebe7a94f232ddba54ee17 https://git.kernel.org/stable/c/19f4f399091478c95947f6bd7ad61622300c30d9 •