LiveActive security incident?Get immediate response
CVE Record

CVE-2022-49394: blk-iolatency: Fix inflight count imbalances and IO hangs on offline

In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix inflight count imbalances and IO hangs on offline iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

CVE-2022-49394 is a Linux kernel block I/O latency bug that can leave internal I/O counters stuck when cgroups are removed. In affected conditions, throttled storage I/O can hang indefinitely. This is an availability risk for Linux systems using cgroup I/O latency controls, not a reported remote compromise issue.

Executive priority

Treat this as a targeted availability issue. It is most relevant for Linux infrastructure using cgroup-based storage controls, especially multi-tenant or container-heavy systems. Patch through normal kernel maintenance, escalating where storage hangs could affect critical services.

Technical view

The flaw is in blk-iolatency inflight accounting. iolatency_pd_offline() could disable tracking without freezing the request queue, unlike iolatency_set_limit(), allowing inflight counts to leak while I/O is active. If a cgroup with leaked counts is later throttled, no completion event wakes queued I/O, causing an indefinite hang. Upstream resolves this by centralizing enable handling through a work item.

Likely exposure

Exposure appears limited to Linux systems with affected kernels where block I/O latency cgroup controls are used or can be manipulated. The source does not establish remote exposure, privilege requirements, distribution package status, or cloud-provider impact.

Exploitation context

The CVE is not in CISA KEV, and the provided sources do not report active exploitation. The upstream description includes a reproducible failure condition involving cgroup I/O latency changes during concurrent disk I/O, but this should be treated as validation context, not evidence of weaponized exploitation.

Researcher notes

Key uncertainty is operational reach: the source describes the race and fix, but not CVSS, required privileges, distro package mappings, or real-world exploit activity. Validation should focus on kernel lineage, cgroup I/O latency usage, and whether the referenced stable commits are present.

Mitigation direction

  • Update affected Linux kernels using vendor or distribution security guidance.
  • Prioritize hosts using cgroup I/O latency controls for workloads or containers.
  • Review kernel vendor advisories for fixed package versions and reboot requirements.
  • Avoid operational reliance on affected iolatency behavior until patched.
  • Monitor storage I/O hangs on systems using block cgroup policies.

Validation and detection

  • Inventory Linux kernel versions across servers and container hosts.
  • Identify systems with cgroup v2 I/O latency controls enabled.
  • Check vendor advisories for backported fixes matching referenced stable commits.
  • Review logs and monitoring for unexplained block I/O stalls or hangs.
  • Confirm patched kernels are booted, not only installed.
Prepared
Confidence
medium
Sources
9

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-49394 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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
8Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux6d482bc5697763eb1214f207286daa201b32d20a, 8c772a9bfc7c07c76f4a58b58910452fbb20843b, 8c772a9bfc7c07c76f4a58b58910452fbb20843b, 8c772a9bfc7c07c76f4a58b58910452fbb20843b, 8c772a9bfc7c07c76f4a58b58910452fbb20843b, 8c772a9bfc7c07c76f4a58b58910452fbb20843b, 8c772a9bfc7c07c76f4a58b58910452fbb20843b, beed6109acd4efc2f1717c31bddcd0ad7ebbf253unaffected
LinuxLinux5.0, 0, 4.19.247, 5.4.198, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.