Linux Kernel bis 6.18.44/7.1.8 V3D Scheduler Timeout sched_main.c drm_sched_run_job_work Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
4.8$0-$5k2.16-

Zusammenfassunginfo

Eine Schwachstelle, die als problematisch eingestuft wurde, wurde in Linux Kernel bis 6.18.44/7.1.8 gefunden. Hierbei geht es um die Funktion drm_sched_run_job_work der Datei drivers/gpu/drm/scheduler/sched_main.c der Komponente V3D Scheduler Timeout Handler. Durch Manipulation mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Die Identifikation der Schwachstelle findet als CVE-2026-74638 statt. Der Angriff ist nur lokal möglich. Es steht kein Exploit zur Verfügung.

Detailsinfo

In Linux Kernel bis 6.18.44/7.1.8 wurde eine Schwachstelle gefunden. Sie wurde als problematisch eingestuft. Das betrifft die Funktion drm_sched_run_job_work der Datei drivers/gpu/drm/scheduler/sched_main.c der Komponente V3D Scheduler Timeout Handler. Mittels Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-667. Die Auswirkungen sind bekannt für die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Serialize the scheduler timeout handlers V3D exposes several independent hardware queues (BIN, RENDER, TFU and CSD) but has only a single, global reset. A timeout on any one queue therefore has to stop, reset and restart the schedulers of every other queue as well. That makes concurrent timeout handlers unsafe. `reset_lock` was never able to make them safe, as a driver-side lock can only cover the driver's &drm_sched_backend_ops.timedout_job callback. The scheduler handles the timed out job and its pending list around that callback, outside of the driver's control, so a global reset triggered by one queue can still interfere with another queue that is in the middle of handling a timeout of its own. Consequently, if a reset happens in the CSD queue while a CL-intensive application is running, the global reset stops and restarts the CL queue's scheduler while that queue is handling a timeout of its own. As drm_sched_stop() and drm_sched_start() subtract and add the credits of every job sitting on the pending list of the scheduler they are called on, and as the CL queue's handler concurrently takes its job off that same list and puts it back, the stop and the start no longer see the same set of jobs. The CL queue is left with more credits in flight than its limit: [ 327.302739] ------------[ cut here ]------------ [ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] [ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT [ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] [ 327.302984] Call trace: [ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P) [ 327.302997] process_scheduled_works+0x180/0x3d0 [ 327.303010] worker_thread+0x268/0x3e8 [ 327.303016] kthread+0x140/0x250 [ 327.303022] ret_from_fork+0x10/0x20 [ 327.303031] ---[ end trace 0000000000000000 ]--- From that point on, the credit count of the CL queue is broken, causing a complete GPU hang and UI freeze. The DRM scheduler already provides a mechanism to serialize the timeout handlers of different schedulers: an ordered workqueue passed as drm_sched_init()'s @timeout_wq parameter. By default, each scheduler queues its timeout work on the system workqueue, which runs the handlers concurrently. Give all of the queues a shared ordered workqueue instead, as recommended by the DRM scheduler documentation for hardware that has distinct queues but resets globally.

Das Advisory findet sich auf git.kernel.org. Die Verwundbarkeit wird seit dem 15.08.2026 als CVE-2026-74638 geführt. Sie ist leicht auszunutzen. Der Angriff muss lokal angegangen werden. Eine Ausnutzung erfordert, dass das Opfer eine spezifische Handlung durchführt. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht.

Ein Aktualisieren auf die Version 6.18.45 oder 7.1.9 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 5884851a096d8afcdf91f0e542bac193035183a6/c22a45817b9c92aa0391db60e2ed467c7e6027d7/4da94744707b27a3ae1197bdd7127da4505dc5b1 lösen.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

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.0
VulDB Meta Temp Score: 4.8

VulDB Base Score: 5.0
VulDB Temp Score: 4.8
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-667
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

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.45/7.1.9
Patch: 5884851a096d8afcdf91f0e542bac193035183a6/c22a45817b9c92aa0391db60e2ed467c7e6027d7/4da94744707b27a3ae1197bdd7127da4505dc5b1

Timelineinfo

15.08.2026 CVE zugewiesen
22.08.2026 +7 Tage Advisory veröffentlicht
22.08.2026 +0 Tage VulDB Eintrag erstellt
22.08.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-74638 (🔒)
GCVE (CVE): GCVE-0-2026-74638
GCVE (VulDB): GCVE-100-394411

Eintraginfo

Erstellt: 22.08.2026 18:26
Anpassungen: 22.08.2026 18:26 (60)
Komplett: 🔍
Cache ID: 216::103

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

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

Do you know our Splunk app?

Download it now for free!