CVE-2024-41054

In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Fix ufshcdclearcmd racing issue

When ufshcdclearcmd is racing with the completion ISR, the completed tag of the request's mqhctx pointer will be set to NULL by the ISR. And ufshcdclearcmd's call to ufshcdmcqreqto_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 ufshcderrhandler step 1 ufshcdtrytoaborttask ufshcdcmdinflight(true) step 3 ufshcdclearcmd ... ufshcdmcqreqtohwq blkmquniquetag rq->mqhctx->queue_num step 5

Thread B ufsmtkmcqintr(cq complete ISR) step 2 scsidone ... _blkmqfreerequest rq->mq_hctx = NULL; step 4

Below is KE back trace:

ufshcdtrytoaborttask: cmd pending in the device. tag = 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194 pc : [0xffffffd589679bf8] blkmquniquetag+0x8/0x14 lr : [0xffffffd5862f95b4] ufshcdmcqsqcleanup+0x6c/0x1cc [ufsmediatekmodise] Workqueue: ufsehwq0 ufshcderrhandler [ufsmediatekmodise] Call trace: dumpbacktrace+0xf8/0x148 showstack+0x18/0x24 dumpstacklvl+0x60/0x7c dumpstack+0x18/0x3c mrdumpcommondie+0x24c/0x398 [mrdump] ipanicdie+0x20/0x34 [mrdump] notifydie+0x80/0xd8 die+0x94/0x2b8 _dokernelfault+0x264/0x298 dopagefault+0xa4/0x4b8 dotranslationfault+0x38/0x54 domemabort+0x58/0x118 el1abort+0x3c/0x5c el1h64synchandler+0x54/0x90 el1h64sync+0x68/0x6c blkmquniquetag+0x8/0x14 ufshcdclearcmd+0x34/0x118 [ufsmediatekmodise] ufshcdtrytoaborttask+0x2c8/0x5b4 [ufsmediatekmodise] ufshcderrhandler+0xa7c/0xfa8 [ufsmediatekmodise] processonework+0x208/0x4fc workerthread+0x228/0x438 kthread+0x104/0x1d4 retfromfork+0x10/0x20