CVE-2024-41053

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix ufshcd_abort_one racing issue<br /> <br /> When ufshcd_abort_one is racing with the completion ISR, the completed tag<br /> of the request&amp;#39;s mq_hctx pointer will be set to NULL by ISR. Return<br /> success when request is completed by ISR because ufshcd_abort_one does not<br /> need to do anything.<br /> <br /> The racing flow is:<br /> <br /> Thread A<br /> ufshcd_err_handler step 1<br /> ...<br /> ufshcd_abort_one<br /> ufshcd_try_to_abort_task<br /> ufshcd_cmd_inflight(true) step 3<br /> ufshcd_mcq_req_to_hwq<br /> blk_mq_unique_tag<br /> rq-&gt;mq_hctx-&gt;queue_num step 5<br /> <br /> Thread B<br /> ufs_mtk_mcq_intr(cq complete ISR) step 2<br /> scsi_done<br /> ...<br /> __blk_mq_free_request<br /> rq-&gt;mq_hctx = NULL; step 4<br /> <br /> Below is KE back trace.<br /> ufshcd_try_to_abort_task: cmd at tag 41 not pending in the device.<br /> ufshcd_try_to_abort_task: cmd at tag=41 is cleared.<br /> Aborting tag 41 / CDB 0x28 succeeded<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194<br /> pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14<br /> lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40 [ufs_mediatek_mod_ise]<br /> do_mem_abort+0x58/0x118<br /> el1_abort+0x3c/0x5c<br /> el1h_64_sync_handler+0x54/0x90<br /> el1h_64_sync+0x68/0x6c<br /> blk_mq_unique_tag+0x8/0x14<br /> ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise]<br /> process_one_work+0x208/0x4fc<br /> worker_thread+0x228/0x438<br /> kthread+0x104/0x1d4<br /> ret_from_fork+0x10/0x20