Skip to main content

iOS CVE-2022-49394

MEDIUM
2025-02-26 416baaa9-dc9f-4396-8d5f-8c081fb06d67
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
Analysis Generated
Mar 28, 2026 - 18:28 vuln.today
Patch released
Mar 28, 2026 - 18:28 nvd
Patch available
CVE Published
Feb 26, 2025 - 07:01 nvd
MEDIUM 5.5

DescriptionCVE.org

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.

AnalysisAI

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. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity.

Technical ContextAI

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. Affected products include: Linux Linux Kernel.

RemediationAI

A vendor patch is available. Apply the latest security update as soon as possible. Apply vendor patches when available. Implement network segmentation and monitoring as interim mitigations.

More in iOS

View all
CVE-2023-43000 HIGH POC
8.8 Nov 05

A use-after-free issue was addressed with improved memory management. Rated high severity (CVSS 8.8), this vulnerability

CVE-2026-20700 HIGH POC
7.8 Feb 11

Apple's kernel across all platforms (iOS, macOS, watchOS, visionOS, tvOS) contains a memory corruption vulnerability (CV

CVE-2023-41974 HIGH POC
7.8 Jan 10

A use-after-free issue was addressed with improved memory management. Rated high severity (CVSS 7.8), this vulnerability

CVE-2014-7992 MEDIUM POC
5.0 Nov 18

The DLSw implementation in Cisco IOS does not initialize packet buffers, which allows remote attackers to obtain sensiti

CVE-2022-48618 HIGH
7.0 Jan 09

The issue was addressed with improved checks. Rated high severity (CVSS 7.0). Actively exploited in the wild (cisa kev)

CVE-2025-66555 HIGH POC
8.8 Dec 04

AirKeyboard iOS App 1.0.5 contains a missing authentication vulnerability that allows unauthenticated attackers to type

CVE-2025-46335 HIGH POC
8.6 May 05

Mobile Security Framework (MobSF) is a security research platform for mobile applications in Android, iOS and Windows Mo

CVE-2021-1385 MEDIUM POC
6.5 Mar 24

A vulnerability in the Cisco IOx application hosting environment of multiple Cisco platforms could allow an authenticate

CVE-2026-31852 CRITICAL
10.0 Mar 11

Arbitrary code execution in Jellyfin iOS GitHub Actions workflow. CVSS 10.0.

CVE-2025-43234 CRITICAL
9.8 Jul 30

Memory corruption vulnerabilities in Apple's graphics texture processing engine across iOS, iPadOS, macOS, tvOS, visionO

CVE-2025-43186 CRITICAL
9.8 Jul 30

Buffer overflow memory corruption in Apple file parsing components allows remote code execution across iOS 18.6, iPadOS

CVE-2023-40414 CRITICAL
9.8 Jan 10

A use-after-free issue was addressed with improved memory management. Rated critical severity (CVSS 9.8), this vulnerabi

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
Container suse/sle-micro-rancher/5.2:latest Image SLES15-SP3-BYOS-Azure Image SLES15-SP3-HPC-BYOS-Azure Image SLES15-SP3-Micro-5-2-BYOS-Azure Image SLES15-SP3-Micro-5-2-BYOS-EC2-HVM Image SLES15-SP3-Micro-5-2-BYOS-GCE Image SLES15-SP3-SAPCAL-Azure Affected
Container suse/sle-micro-rancher/5.3:latest Container suse/sle-micro-rancher/5.4:latest Image SLES15-SP4-BYOS Image SLES15-SP4-BYOS-Azure Image SLES15-SP4-BYOS-EC2 Image SLES15-SP4-BYOS-GCE Image SLES15-SP4-CHOST-BYOS Image SLES15-SP4-CHOST-BYOS-Aliyun Image SLES15-SP4-CHOST-BYOS-Azure Image SLES15-SP4-CHOST-BYOS-EC2 Image SLES15-SP4-CHOST-BYOS-GCE Image SLES15-SP4-CHOST-BYOS-SAP-CCloud Image SLES15-SP4-HPC-BYOS Image SLES15-SP4-HPC-BYOS-Azure Image SLES15-SP4-HPC-BYOS-EC2 Image SLES15-SP4-HPC-BYOS-GCE Image SLES15-SP4-HPC-EC2 Image SLES15-SP4-HPC-GCE Image SLES15-SP4-Hardened-BYOS Image SLES15-SP4-Hardened-BYOS-Azure Image SLES15-SP4-Hardened-BYOS-EC2 Image SLES15-SP4-Hardened-BYOS-GCE Image SLES15-SP4-Manager-Proxy-4-3-BYOS Image SLES15-SP4-Manager-Proxy-4-3-BYOS-Azure Image SLES15-SP4-Manager-Proxy-4-3-BYOS-EC2 Image SLES15-SP4-Manager-Proxy-4-3-BYOS-GCE Image SLES15-SP4-Manager-Server-4-3-BYOS Image SLES15-SP4-Manager-Server-4-3-BYOS-Azure Image SLES15-SP4-Manager-Server-4-3-BYOS-EC2 Image SLES15-SP4-Manager-Server-4-3-BYOS-GCE Image SLES15-SP4-Micro-5-3 Image SLES15-SP4-Micro-5-3-BYOS Image SLES15-SP4-Micro-5-3-BYOS-Azure Image SLES15-SP4-Micro-5-3-BYOS-EC2 Image SLES15-SP4-Micro-5-3-BYOS-GCE Image SLES15-SP4-Micro-5-3-EC2 Image SLES15-SP4-Micro-5-4 Image SLES15-SP4-Micro-5-4-BYOS Image SLES15-SP4-Micro-5-4-BYOS-Azure Image SLES15-SP4-Micro-5-4-BYOS-EC2 Image SLES15-SP4-Micro-5-4-BYOS-GCE Image SLES15-SP4-Micro-5-4-EC2 Image SLES15-SP4-Micro-5-4-GCE Image SLES15-SP4-SAP Image SLES15-SP4-SAP-Azure Image SLES15-SP4-SAP-EC2 Image SLES15-SP4-SAP-GCE Image SLES15-SP4-SAPCAL Image SLES15-SP4-SAPCAL-Azure Image SLES15-SP4-SAPCAL-EC2 Image SLES15-SP4-SAPCAL-GCE Affected
Container suse/sle-micro/base-5.5:2.0.4-5.8.160 Image SLES15-SP5-BYOS-Azure Image SLES15-SP5-BYOS-EC2 Image SLES15-SP5-BYOS-GCE Image SLES15-SP5-CHOST-BYOS-Aliyun Image SLES15-SP5-CHOST-BYOS-Azure Image SLES15-SP5-CHOST-BYOS-EC2 Image SLES15-SP5-CHOST-BYOS-GCE Image SLES15-SP5-CHOST-BYOS-GDC Image SLES15-SP5-CHOST-BYOS-SAP-CCloud Image SLES15-SP5-EC2 Image SLES15-SP5-GCE Image SLES15-SP5-HPC-BYOS-Azure Image SLES15-SP5-HPC-BYOS-EC2 Image SLES15-SP5-HPC-BYOS-GCE Image SLES15-SP5-Hardened-BYOS-Azure Image SLES15-SP5-Hardened-BYOS-EC2 Image SLES15-SP5-Hardened-BYOS-GCE Image SLES15-SP5-Manager-Proxy-5-0-BYOS Image SLES15-SP5-Manager-Proxy-5-0-BYOS-Azure Image SLES15-SP5-Manager-Proxy-5-0-BYOS-EC2 Image SLES15-SP5-Manager-Proxy-5-0-BYOS-GCE Image SLES15-SP5-Manager-Server-5-0 Image SLES15-SP5-Manager-Server-5-0-Azure-llc Image SLES15-SP5-Manager-Server-5-0-Azure-ltd Image SLES15-SP5-Manager-Server-5-0-BYOS Image SLES15-SP5-Manager-Server-5-0-BYOS-Azure Image SLES15-SP5-Manager-Server-5-0-BYOS-EC2 Image SLES15-SP5-Manager-Server-5-0-BYOS-GCE Image SLES15-SP5-Manager-Server-5-0-EC2-llc Image SLES15-SP5-Manager-Server-5-0-EC2-ltd Image SLES15-SP5-Micro-5-5 Image SLES15-SP5-Micro-5-5-Azure Image SLES15-SP5-Micro-5-5-BYOS Image SLES15-SP5-Micro-5-5-BYOS-Azure Image SLES15-SP5-Micro-5-5-BYOS-EC2 Image SLES15-SP5-Micro-5-5-BYOS-GCE Image SLES15-SP5-Micro-5-5-EC2 Image SLES15-SP5-Micro-5-5-GCE Image SLES15-SP5-SAPCAL-Azure Image SLES15-SP5-SAPCAL-EC2 Image SLES15-SP5-SAPCAL-GCE Affected
Container suse/sle-micro/kvm-5.5:2.0.4-3.5.304 Affected
Container suse/sle-micro/rt-5.5:2.0.4-4.5.352 Affected

Share

CVE-2022-49394 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy