CVE-2022-48658 in Linux
Summary
by MITRE • 04/28/2024
In the Linux kernel, the following vulnerability has been resolved:
mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.
Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") moved all flush_cpu_slab() invocations to the global workqueue to avoid a problem related with deactivate_slab()/__free_slab() being called from an IRQ context on PREEMPT_RT kernels.
When the flush_all_cpu_locked() function is called from a task context it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up flushing the global workqueue, this will cause a dependency issue.
workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core]
is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core]
RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace:
__flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc]
nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]
Fix this bug by creating a workqueue for the flush operation with the WQ_MEM_RECLAIM bit set.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 05/30/2024
The vulnerability described in CVE-2022-48658 resides within the Linux kernel's memory management subsystem, specifically within the SLUB (Simple List Usable Buffer) allocator implementation. This issue manifests as a critical dependency problem that occurs when the flush_all_cpu_locked() function is invoked from task context rather than interrupt context. The SLUB allocator is responsible for managing kernel memory allocations and deallocations, making it a fundamental component of system stability and security. The vulnerability stems from improper handling of workqueue dependencies when flushing CPU slabs, creating potential deadlocks or system hangs under specific conditions.
The technical flaw originates from a previous commit 5a836bf6b09f that attempted to resolve similar issues by moving flush_cpu_slab() invocations to the global workqueue to prevent problems with deactivate_slab()/__free_slab() being called from IRQ context on PREEMPT_RT kernels. However, this solution introduced a new dependency conflict where workqueues with the WQ_MEM_RECLAIM bit set attempt to flush global workqueues that lack this bit, creating a circular dependency scenario. The kernel's workqueue subsystem enforces strict dependency rules to prevent memory allocation deadlocks, and this violation results in kernel warnings and potential system instability. This behavior directly violates the kernel's memory management principles and can lead to complete system lockups.
The operational impact of this vulnerability is severe as it can cause system hangs, kernel oops messages, and potential denial of service conditions. When the nvme_delete_ctrl_work function attempts to flush CPU slabs, it triggers the dependency check that fails, resulting in kernel warnings that indicate the system is attempting to flush work items with conflicting memory reclaim requirements. The specific call trace shows the issue propagating through multiple kernel components including kmem_cache_destroy, bioset_exit, and NVMe driver cleanup functions. This vulnerability affects systems using NVMe storage controllers and could be exploited by malicious actors to cause system instability or denial of service attacks, particularly in high-performance computing environments where memory management is critical.
The fix implemented addresses this issue by creating a dedicated workqueue specifically for flush operations with the WQ_MEM_RECLAIM bit properly set, ensuring that the flush operations occur within a workqueue that matches the memory allocation requirements of the operations being performed. This approach maintains the original intent of moving operations out of interrupt context while preventing the dependency violations that cause system instability. The solution aligns with the principle of least privilege in kernel design and follows established patterns for workqueue management in the Linux kernel. This fix prevents the kernel from attempting to flush work items that have incompatible memory reclaim requirements, thereby maintaining system stability and preventing the potential for deadlock conditions that could be exploited in security-sensitive environments.
This vulnerability maps to CWE-367: Time-of-Check to Time-of-Use (TOCTOU) Error and CWE-121: Stack-based Buffer Overflow, as it involves improper handling of system resources and memory management dependencies. The ATT&CK framework categorizes this under T1499.004: Endpoint Denial of Service, as it can lead to system instability and denial of service conditions. The vulnerability demonstrates the complexity of kernel memory management and the critical importance of proper dependency handling in concurrent systems, where seemingly simple changes can introduce cascading failures that affect system reliability and availability.