In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
drainworkqueue() cannot be called safely in a spinlocked context due to possible task rescheduling. In the multi-task scenario, calling queuework() while drainworkqueue() will lead to a Call Trace as pushing a work on a draining workqueue is not permitted in spinlocked context. Call Trace: <TASK> ? _warn+0x7d/0x140 ? _queuework+0x2b2/0x440 ? reportbug+0x1f8/0x200 ? handlebug+0x3c/0x70 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? _queuework+0x2b2/0x440 queueworkon+0x28/0x30 idxdmiscthread+0x303/0x5a0 [idxd] ? _schedule+0x369/0xb40 ? _pfxirqthreadfn+0x10/0x10 ? irqthread+0xbc/0x1b0 irqthreadfn+0x21/0x70 irqthread+0x102/0x1b0 ? preemptcountadd+0x74/0xa0 ? _pfxirqthreaddtor+0x10/0x10 ? _pfxirqthread+0x10/0x10 kthread+0x103/0x140 ? _pfxkthread+0x10/0x10 retfromfork+0x31/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK>
The current implementation uses a spinlock to protect event log workqueue and will lead to the Call Trace due to potential task rescheduling.
To address the locking issue, convert the spinlock to mutex, allowing the drain_workqueue() to be called in a safe mutex-locked context.
This change ensures proper synchronization when accessing the event log workqueue, preventing potential Call Trace and improving the overall robustness of the code.