CVE-2022-50554
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-07

Last updated on: 2026-02-06

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: blk-mq: avoid double ->queue_rq() because of early timeout David Jeffery found one double ->queue_rq() issue, so far it can be triggered in VM use case because of long vmexit latency or preempt latency of vCPU pthread or long page fault in vCPU pthread, then block IO req could be timed out before queuing the request to hardware but after calling blk_mq_start_request() during ->queue_rq(), then timeout handler may handle it by requeue, then double ->queue_rq() is caused, and kernel panic. So far, it is driver's responsibility to cover the race between timeout and completion, so it seems supposed to be solved in driver in theory, given driver has enough knowledge. But it is really one common problem, lots of driver could have similar issue, and could be hard to fix all affected drivers, even it isn't easy for driver to handle the race. So David suggests this patch by draining in-progress ->queue_rq() for solving this issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-07
Last Modified
2026-02-06
Generated
2026-05-07
AI Q&A
2025-10-07
EPSS Evaluated
2026-05-05
NVD
CVE-2022-50554
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves a double call to the function queue_rq() due to an early timeout. It can be triggered in virtual machine scenarios where delays like long vmexit latency or preempt latency cause a block IO request to time out before it is queued to hardware but after blk_mq_start_request() has been called. The timeout handler may then requeue the request, causing queue_rq() to be called twice, which leads to a kernel panic. The issue arises because drivers are responsible for handling the race condition between timeout and completion, but this is a common problem that is difficult to fix across all drivers. The suggested fix involves draining in-progress queue_rq() calls to prevent this issue.


How can this vulnerability impact me? :

This vulnerability can cause a kernel panic in systems running the affected Linux kernel, especially in virtual machine environments. A kernel panic results in a system crash, leading to downtime, potential data loss, and disruption of services relying on the affected system.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is related to a double queue_rq() call in the Linux kernel blk-mq subsystem causing kernel panic. Since it is a kernel-level issue triggered by specific timing conditions in VM use cases, immediate mitigation would involve updating the Linux kernel to a version that includes the patch which drains in-progress queue_rq() calls to avoid the race condition. There are no specific driver-level fixes that are easy to apply, so applying the official kernel patch or upgrading the kernel is the recommended step.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart