CVE-2022-50552: blk-mq: use quiesced elevator switch when reinitializing queues
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
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel reliability vulnerability in block queue handling. During queue reinitialization, background work can race with an elevator scheduler switch, leaving the kernel using freed or invalid scheduler state. The documented impact is kernel panic, which can cause service interruption on affected Linux systems.
Executive priority
Treat this as a stability and availability risk rather than a confirmed intrusion risk. Prioritize patching on critical Linux infrastructure, storage-heavy workloads, and systems where unexpected kernel panics would disrupt customer-facing services or operations.
Technical view
The flaw is a race in blk-mq during hardware queue reinitialization. Freezing the queue blocks new request allocation but does not stop hctx run_work. That work can observe an elevator pointer being torn down, causing use-after-free or NULL dereference paths such as kyber_has_work and blk_mq_run_work_fn.
Likely exposure
Exposure applies to Linux systems running affected kernel versions listed by the CVE source, including 4.19, 5.10.258, 5.15.209, 5.19.17, 6.0.3, and 6.1. Confirm distro backports because package versions may not map directly to upstream kernel numbers.
Exploitation context
The provided sources do not report active exploitation, and KEV is false. The source describes a race causing kernel panics during queue reinitialization, with an NVMe controller reset shown as an example. There is no public exploit path or attacker prerequisite stated in the bundle.
Researcher notes
Evidence is clear on root cause and fix direction, but incomplete on exploitability, CVSS, prerequisites, and affected distro packages. Avoid assuming remote exploitability. The useful validation path is kernel provenance, stable-commit inclusion, and crash-signature correlation.
Mitigation direction
Apply vendor kernel updates that include the referenced upstream stable fixes.
Confirm fixes through your distribution advisory, not only upstream version numbers.
Prioritize systems where kernel panics cause high business impact.
Schedule reboots where required for the updated kernel to take effect.
Monitor for recurring blk-mq, kyber, or NVMe reset panics.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and images.
Check whether each kernel includes one of the referenced stable commits or a vendor backport.
Review crash logs for blk_mq_run_work_fn, kyber_has_work, or elevator teardown traces.
Validate updated kernels in staging before broad production rollout.
Confirm production systems booted into the patched kernel after maintenance.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-50552 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Oct 7, 2025, 15:21 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.