CVE-2023-53760

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

scsi: ufs: core: mcq: Fix &hwq->cq_lock deadlock issue

When ufshcderrhandler() is executed, CQ event interrupt can enter waiting for the same lock. This can happen in ufshcdhandlemcqcqevents() and also in ufsmtkmcqintr(). The following warning message will be generated when &hwq->cqlock is used in IRQ context with IRQ enabled. Use ufshcdmcqpollcqelock() with spinlockirqsave instead of spin_lock to resolve the deadlock issue.

[name:lockdep&]WARNING: inconsistent lock state [name:lockdep&]-------------------------------- [name:lockdep&]inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. ffffff8028444600 (&hwq->cqlock){?.-.}-{2:2}, at: ufshcdmcqpollcqelock+0x30/0xe0 [name:lockdep&]{IN-HARDIRQ-W} state was registered at: lockacquire+0x17c/0x33c rawspinlock+0x5c/0x7c ufshcdmcqpollcqelock+0x30/0xe0 ufsmtkmcqintr+0x60/0x1bc [ufsmediatekmod] __handleirqeventpercpu+0x140/0x3ec handleirqevent+0x50/0xd8 handlefasteoiirq+0x148/0x2b0 generichandledomainirq+0x4c/0x6c gichandleirq+0x58/0x134 callonirqstack+0x40/0x74 dointerrupthandler+0x84/0xe4 el1interrupt+0x3c/0x78 <snip>

Possible unsafe locking scenario: CPU0 ---- lock(&hwq->cqlock); <Interrupt> lock(&hwq->cqlock); *** DEADLOCK *** 2 locks held by kworker/u16:4/260:

[name:lockdep&] stack backtrace: CPU: 7 PID: 260 Comm: kworker/u16:4 Tainted: G S W OE 6.1.17-mainline-android14-2-g277223301adb #1 Workqueue: ufsehwq0 ufshcderr_handler

Call trace: dumpbacktrace+0x10c/0x160 showstack+0x20/0x30 dumpstacklvl+0x98/0xd8 dumpstack+0x20/0x60 printusagebug+0x584/0x76c marklockirq+0x488/0x510 marklock+0x1ec/0x25c __lockacquire+0x4d8/0xffc lockacquire+0x17c/0x33c rawspinlock+0x5c/0x7c ufshcdmcqpollcqelock+0x30/0xe0 ufshcdpoll+0x68/0x1b0 ufshcdtransferreqcompl+0x9c/0xc8 ufshcderrhandler+0x3bc/0xea0 processonework+0x2f4/0x7e8 workerthread+0x234/0x450 kthread+0x110/0x134 retfromfork+0x10/0x20