CVE-2022-49394
- Source
- https://cve.org/CVERecord?id=CVE-2022-49394
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-49394.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2022-49394
- Downstream
- Related
- Published
- 2025-02-26T02:11:25.197Z
- Modified
- 2026-05-18T05:56:58.463083329Z
- Summary
- blk-iolatency: Fix inflight count imbalances and IO hangs on offline
- Details
-
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, iolatencysetlimit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero.
Unfortunately, iolatencysetlimit() isn't the only place where the enabled counter is manipulated. iolatencypdoffline() 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 cssforeachdescendantpre(prog['blkcgroot'].css.addressof_()): for pos in hlistforeach(containerof(css, 'struct blkcg', 'css').blkglist): blkg = containerof(pos, 'struct blkcggq', 'blkcgnode') pd = blkg.pd[prog['blkcgpolicyiolatency'].plid] if pd.value() == 0: continue iolat = containerof(pd, 'struct iolatencygrp', 'pd') inflight = iolat.rqwait.inflight.counter.value() if inflight: print(f'inflight={inflight} {diskname(blkg.q.disk).decode("utf-8")} ' f'{cgrouppath(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 iolatencysetminlatnsec() which is called from both iolatencysetlimit() and iolatencypdoffline() paths. Punting to a work item is necessary as iolatencypdoffline() 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.
- Database specific
{ "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49394.json", "cna_assigner": "Linux" }- References
-
- https://git.kernel.org/stable/c/515d077ee3085ae343b6bea7fd031f9906645f38
- https://git.kernel.org/stable/c/5b0ff3ebbef791341695b718f8d2870869cf1d01
- https://git.kernel.org/stable/c/77692c02e1517c54f2fd0535f41aa4286ac9f140
- https://git.kernel.org/stable/c/8a177a36da6c54c98b8685d4f914cb3637d53c0d
- https://git.kernel.org/stable/c/968f7a239c590454ffba79c126fbe0e963a0ba78
- https://git.kernel.org/stable/c/a30acbb5dfb7bcc813ad6a18ca31011ac44e5547
- https://git.kernel.org/stable/c/d19fa8f252000d141f9199ca32959c50314e1f05
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49394.json
- https://nvd.nist.gov/vuln/detail/CVE-2022-49394
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced6d482bc5697763eb1214f207286daa201b32d20aFixed515d077ee3085ae343b6bea7fd031f9906645f38
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced8c772a9bfc7c07c76f4a58b58910452fbb20843bFixedd19fa8f252000d141f9199ca32959c50314e1f05Fixed77692c02e1517c54f2fd0535f41aa4286ac9f140Fixeda30acbb5dfb7bcc813ad6a18ca31011ac44e5547Fixed968f7a239c590454ffba79c126fbe0e963a0ba78Fixed5b0ff3ebbef791341695b718f8d2870869cf1d01Fixed8a177a36da6c54c98b8685d4f914cb3637d53c0d
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced0 Unknown introduced commit / All previous commits are affectedLast affectedbeed6109acd4efc2f1717c31bddcd0ad7ebbf253
Affected versions
v2.*
v3.*
v4.*
Linux / Kernel
Package
- Name
- Kernel
Affected ranges
- Type
- ECOSYSTEM
- Events
-
Introduced0Unknown introduced version / All previous versions are affectedFixed4.19.247
- Type
- ECOSYSTEM
- Events
-
Introduced4.20.0Fixed5.4.198
- Type
- ECOSYSTEM
- Events
-
Introduced5.0.0Fixed5.10.121
- Type
- ECOSYSTEM
- Events
-
Introduced5.5.0Fixed5.15.46
- Type
- ECOSYSTEM
- Events
-
Introduced5.11.0Fixed5.17.14
- Type
- ECOSYSTEM
- Events
-
Introduced5.16.0Fixed5.18.3