CVE-2022-50086: block: don't allow the same type rq_qos add more than once
In the Linux kernel, the following vulnerability has been resolved:
block: don't allow the same type rq_qos add more than once
In our test of iocost, we encountered some list add/del corruptions of
inner_walk list in ioc_timer_fn.
The reason can be described as follows:
cpu 0 cpu 1
ioc_qos_write ioc_qos_write
ioc = q_to_ioc(queue);
if (!ioc) {
ioc = kzalloc();
ioc = q_to_ioc(queue);
if (!ioc) {
ioc = kzalloc();
...
rq_qos_add(q, rqos);
}
...
rq_qos_add(q, rqos);
...
}
When the io.cost.qos file is written by two cpus concurrently, rq_qos may
be added to one disk twice. In that case, there will be two iocs enabled
and running on one disk. They own different iocgs on their active list. In
the ioc_timer_fn function, because of the iocgs from two iocs have the
same root iocg, the root iocg's walk_list may be overwritten by each other
and this leads to list add/del corruptions in building or destroying the
inner_walk list.
And so far, the blk-rq-qos framework works in case that one instance for
one type rq_qos per queue by default. This patch make this explicit and
also fix the crash above.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can crash a system when the IO cost QoS setting is written concurrently. The public record describes kernel list corruption after duplicate rq_qos objects are added to one disk. No public source in the bundle reports exploitation or a CVSS score.
Executive priority
Treat as a reliability and availability risk for Linux infrastructure using IO cost QoS. Prioritize patching where kernel crashes would affect production workloads, but do not treat it as confirmed actively exploited based on this bundle.
Technical view
A race in the block rq_qos framework lets the same rq_qos type be added more than once per queue during concurrent io.cost.qos writes. Duplicate ioc instances can corrupt iocg walk_list handling in ioc_timer_fn, causing list add/delete corruption and a crash. The fix makes the one-instance-per-type rule explicit.
Likely exposure
Exposure appears limited to Linux systems running affected kernels where io.cost.qos is used or writable. The bundle lists affected Linux versions but does not provide distribution package mappings, privilege requirements, or default configuration details.
Exploitation context
The source describes a concurrent write race, not a proven exploit. KEV is false, and the bundle provides no evidence of active exploitation, public weaponization, or remote reachability.
Researcher notes
Key unknowns are privilege boundary, reachable configurations, and affected distribution backports. The root condition is duplicate rq_qos registration during concurrent io.cost.qos writes, with corruption in ioc_timer_fn inner_walk handling.
Mitigation direction
Update to a Linux kernel or distribution package containing the referenced stable fixes.
Check vendor advisories for exact fixed package versions in your distribution.
Restrict who can modify io.cost.qos and related IO controller settings.
Avoid concurrent automation writes to io.cost.qos until patched.
Validation and detection
Inventory Linux kernel versions across servers and appliances.
Check whether cgroup IO cost QoS is enabled or managed operationally.
Confirm vendor kernel packages include one of the referenced fixes.
Review kernel logs for list corruption or unexplained crashes around IO QoS changes.
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-50086 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
5Source 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.
Jun 18, 2025, 11:02 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.