Linux Kernel bis 5.18.2 iolatency_set_limit Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
5.5$0-$5k0.00

Zusammenfassunginfo

Eine kritische Schwachstelle wurde in Linux Kernel bis 5.18.2 entdeckt. Es geht dabei um die Funktion iolatency_set_limit. Durch Manipulation mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Verwundbarkeit ist als CVE-2022-49394 gelistet. Es existiert kein Exploit. Ein Upgrade der betroffenen Komponente wird empfohlen.

Detailsinfo

Eine Schwachstelle wurde in Linux Kernel bis 5.18.2 entdeckt. Sie wurde als kritisch eingestuft. Dies betrifft die Funktion iolatency_set_limit. Dank Manipulation mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-404. Auswirkungen hat dies auf die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

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.

Bereitgestellt wird das Advisory unter git.kernel.org. Die Verwundbarkeit wird seit dem 26.02.2025 mit der eindeutigen Identifikation CVE-2022-49394 gehandelt. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht.

Ein Aktualisieren auf die Version 4.19.247, 5.4.198, 5.10.121, 5.15.46, 5.17.14 oder 5.18.3 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 515d077ee3085ae343b6bea7fd031f9906645f38/d19fa8f252000d141f9199ca32959c50314e1f05/77692c02e1517c54f2fd0535f41aa4286ac9f140/a30acbb5dfb7bcc813ad6a18ca31011ac44e5547/968f7a239c590454ffba79c126fbe0e963a0ba78/5b0ff3ebbef791341695b718f8d2870869cf1d01/8a177a36da6c54c98b8685d4f914cb3637d53c0d lösen. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 5.6
VulDB Meta Temp Score: 5.5

VulDB Base Score: 5.7
VulDB Temp Score: 5.5
VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

NVD Base Score: 5.5
NVD Vector: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-404
CAPEC: 🔍
ATT&CK: 🔍

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

Verfügbarkeit: 🔍
Status: Nicht definiert

EPSS Score: 🔍
EPSS Percentile: 🔍

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔍

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔍

Upgrade: Kernel 4.19.247/5.4.198/5.10.121/5.15.46/5.17.14/5.18.3
Patch: 515d077ee3085ae343b6bea7fd031f9906645f38/d19fa8f252000d141f9199ca32959c50314e1f05/77692c02e1517c54f2fd0535f41aa4286ac9f140/a30acbb5dfb7bcc813ad6a18ca31011ac44e5547/968f7a239c590454ffba79c126fbe0e963a0ba78/5b0ff3ebbef791341695b718f8d2870869cf1d01/8a177a36da6c54c98b8685d4f914cb3637d53c0d

Timelineinfo

26.02.2025 🔍
26.02.2025 +0 Tage 🔍
26.02.2025 +0 Tage 🔍
21.10.2025 +237 Tage 🔍

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2022-49394 (🔍)
GCVE (CVE): GCVE-0-2022-49394
GCVE (VulDB): GCVE-100-296957

Eintraginfo

Erstellt: 26.02.2025 08:40
Aktualisierung: 21.10.2025 19:07
Anpassungen: 26.02.2025 08:40 (58), 21.10.2025 19:07 (11)
Komplett: 🔍
Cache ID: 216::103

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Do you want to use VulDB in your project?

Use the official API to access entries easily!