CVE-2024-35991

In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
drain_workqueue() cannot be called safely in a spinlocked context due to
possible task rescheduling. In the multi-task scenario, calling
queue_work() while drain_workqueue() 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 ? __queue_work+0x2b2/0x440 ?
report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ?
asm_exc_invalid_op+0x1a/0x20 ? __queue_work+0x2b2/0x440
queue_work_on+0x28/0x30 idxd_misc_thread+0x303/0x5a0 [idxd] ?
__schedule+0x369/0xb40 ? __pfx_irq_thread_fn+0x10/0x10 ?
irq_thread+0xbc/0x1b0 irq_thread_fn+0x21/0x70 irq_thread+0x102/0x1b0 ?
preempt_count_add+0x74/0xa0 ? __pfx_irq_thread_dtor+0x10/0x10 ?
__pfx_irq_thread+0x10/0x10 kthread+0x103/0x140 ? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10
ret_from_fork_asm+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.