Linux Kernel bis 6.18.41/7.1.5/7.2-rc4 ublk ublk_ctrl_start_dev Denial of Service

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

Zusammenfassunginfo

Eine Schwachstelle, die als kritisch eingestuft wurde, wurde in Linux Kernel bis 6.18.41/7.1.5/7.2-rc4 gefunden. Hierbei betrifft es die Funktion ublk_ctrl_start_dev der Komponente ublk. Mittels Manipulieren mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Schwachstelle wird als CVE-2026-68173 gehandelt. Der Angriff lässt sich über das Netzwerk starten. Es ist kein Exploit verfügbar.

Detailsinfo

Es wurde eine kritische Schwachstelle in Linux Kernel bis 6.18.41/7.1.5/7.2-rc4 gefunden. Es betrifft die Funktion ublk_ctrl_start_dev der Komponente ublk. Mittels Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Im Rahmen von CWE wurde eine Klassifizierung als CWE-400 vorgenommen. Auswirkungen hat dies auf die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition "every queue has fetched all I/O commands", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.

Bereitgestellt wird das Advisory unter git.kernel.org. Die Identifikation der Schwachstelle wird seit dem 30.07.2026 mit CVE-2026-68173 vorgenommen. Die Ausnutzbarkeit gilt als leicht. Der Angriff kann über das Netzwerk erfolgen. Es sind zwar technische Details, jedoch kein verfügbarer Exploit zur Schwachstelle bekannt. Ein Exploit zur Schwachstelle wird momentan etwa USD $0-$5k kosten (Preisberechnung vom 10.08.2026). Als Angriffstechnik weist das MITRE ATT&CK Projekt die ID T1499 aus.

Ein Aktualisieren auf die Version 6.18.42, 7.1.6 oder 7.2-rc5 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 7dd26adf7e7d482af524e3a0cca4a81ef7c159d0/8f188dd11a1c2ad94caeaee36ef68bb8221d4a12/432a9b2780c0a01caf547bd1fc2fcf28aeb8d173 lösen.

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: 6.5
VulDB Meta Temp Score: 6.2

VulDB Base Score: 6.5
VulDB Temp Score: 6.2
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

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-400 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

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

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.18.42/7.1.6/7.2-rc5
Patch: 7dd26adf7e7d482af524e3a0cca4a81ef7c159d0/8f188dd11a1c2ad94caeaee36ef68bb8221d4a12/432a9b2780c0a01caf547bd1fc2fcf28aeb8d173

Timelineinfo

30.07.2026 CVE zugewiesen
10.08.2026 +11 Tage Advisory veröffentlicht
10.08.2026 +0 Tage VulDB Eintrag erstellt
10.08.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-68173 (🔒)
GCVE (CVE): GCVE-0-2026-68173
GCVE (VulDB): GCVE-100-387525

Eintraginfo

Erstellt: 10.08.2026 15:45
Anpassungen: 10.08.2026 15:45 (59)
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!