CVE-2022-50552 in Linux
Summary
by MITRE • 10/07/2025
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: use quiesced elevator switch when reinitializing queues
The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally.
nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI
Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70
...
Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 04/20/2026
The vulnerability identified as CVE-2022-50552 resides within the Linux kernel's block multi-queue subsystem, specifically affecting how hardware queues are reinitialized during controller resets. This issue manifests when the kernel attempts to switch elevator algorithms while hardware contexts are actively running, creating a race condition that can lead to critical system instability. The problem occurs in the blk-mq subsystem where the queue freezing mechanism fails to prevent active work items from executing with stale elevator pointers, resulting in potential use-after-free conditions that can terminate the kernel through NULL pointer dereferences.
The technical flaw stems from improper synchronization between queue reinitialization operations and active hardware context work items. During NVMe controller resets, the system freezes queues but does not adequately prevent ongoing work from accessing elevator data structures that are being torn down. The hctx work items continue to execute with references to elevator pointers that have already been freed or modified, creating a scenario where a kernel thread attempts to dereference a NULL pointer at address 0x0000000000000008. This particular memory access pattern triggers a kernel NULL pointer dereference error that manifests as a kernel panic, as evidenced by the oops trace showing the kyber_has_work function failing at offset 0x29 within the kernel code execution.
This vulnerability directly maps to CWE-416, which describes the use of freed memory condition, and aligns with ATT&CK technique T1490 for Deployment of Malicious Code and T1566 for Phishing. The operational impact of this flaw extends beyond simple system crashes to potentially enabling privilege escalation or denial of service attacks against systems running affected kernel versions. When the kernel encounters this race condition during hardware controller resets, particularly in storage-intensive environments using NVMe devices, the system becomes unstable and may require complete rebooting, causing service interruptions and potential data loss.
The mitigation strategy involves implementing a quiesced elevator switch mechanism that properly synchronizes the elevator switching process with active work items, ensuring that no stale references are accessed during the transition. The fix modifies the code to use a static variable for the previous elevator pointer, limiting its scope to local usage only and preventing external access to potentially freed memory locations. This approach aligns with kernel security best practices for concurrent access control and memory management, addressing the root cause of the race condition by ensuring proper synchronization between queue reinitialization and active work execution. The solution follows established patterns for handling concurrent data structure modifications in kernel space, similar to those recommended in the Linux kernel documentation for managing shared resources under high-concurrency scenarios.
The vulnerability represents a critical security concern for enterprise storage systems where NVMe controllers are frequently reset or reconfigured, particularly in high-availability environments where system stability is paramount. Organizations should prioritize patching affected systems, as the race condition can be exploited to cause system crashes or potentially enable more sophisticated attacks if combined with other vulnerabilities. The fix demonstrates the importance of careful synchronization in kernel-level programming, where even seemingly minor race conditions can result in catastrophic system failures. This vulnerability highlights the need for comprehensive testing of concurrent access patterns in storage subsystems and reinforces the principle that kernel-level memory management must account for all possible execution paths and timing scenarios.