In the Linux kernel, the following vulnerability has been resolved:
mm: slub: fix flushcpuslab()/_freeslab() invocations in task context.
Commit 5a836bf6b09f ("mm: slub: move flushcpuslab() invocations freeslab() invocations out of IRQ context") moved all flushcpuslab() invocations to the global workqueue to avoid a problem related with deactivateslab()/freeslab() being called from an IRQ context on PREEMPTRT kernels.
When the flushallcpulocked() function is called from a task context it may happen that a workqueue with WQMEM_RECLAIM bit set ends up flushing the global workqueue, this will cause a dependency issue.
workqueue: WQMEMRECLAIM nvme-delete-wq:nvmedeletectrlwork [nvmecore] is flushing !WQMEMRECLAIM events:flushcpuslab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 checkflushdependency+0x10a/0x120 Workqueue: nvme-delete-wq nvmedeletectrlwork [nvmecore] RIP: 0010:checkflushdependency+0x10a/0x120[ 453.262125] Call Trace: _flushwork.isra.0+0xbf/0x220 ? _queuework+0x1dc/0x420 flushallcpuslocked+0xfb/0x120 _kmemcacheshutdown+0x2b/0x320 kmemcachedestroy+0x49/0x100 biosetexit+0x143/0x190 blkreleasequeue+0xb9/0x100 kobjectcleanup+0x37/0x130 nvmefcctrlfree+0xc6/0x150 [nvmefc] nvmefreectrl+0x1ac/0x2b0 [nvme_core]
Fix this bug by creating a workqueue for the flush operation with the WQMEMRECLAIM bit set.