CVE-2026-74638 in Linux
Zusammenfassung
von VulDB • 22.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drm/v3d: Zeitüberschreitungs-Handler des Schedulers serialisieren
V3D bietet mehrere unabhängige Hardware-Warteschlangen (BIN, RENDER, TFU und CSD) an, verfügt jedoch nur über einen einzigen globalen Reset. Eine Timeout auf einer beliebigen Warteschlange muss daher die Scheduler aller anderen Warteschlangen stoppen, zurücksetzen und neu starten. Dies macht parallele Zeitüberschreitungs-Handler unsicher.
`reset_lock` konnte diese niemals sicher machen, da ein treiberseitiger Lock nur den `&drm_sched_backend_ops.timedout_job`-Callback des Treibers abdecken kann. Der Scheduler verarbeitet das zeitüberschrittene Job und dessen Warteschlange (pending list) außerhalb dieses Callbacks, also unabhängig von der Kontrolle des Treibers; daher kann ein globaler Reset, ausgelöst durch eine Warteschlange, weiterhin mit einer anderen Warteschlange interferieren, die sich mitten in der Verarbeitung eines eigenen Timeouts befindet.
Folglich führt ein Reset im CSD-Warteschlangen-Thread während der Ausführung einer CL-intensiven Anwendung dazu, dass der globale Reset den Scheduler der CL-Warteschlange stoppt und neu startet, während diese Warteschlange selbst einen Timeout verarbeitet. Da `drm_sched_stop()` und `drm_sched_start()` die Credits jedes Jobs abziehen bzw. hinzufügen, der in der pending list des Schedulers steht, auf dem sie aufgerufen werden, und da der Handler der CL-Warteschlage parallel seinen Job von derselben Liste entfernt und wieder hinzufügt, sehen Stop- und Start-Vorgänge nicht mehr dieselbe Menge an Jobs vor sich. Die CL-Warteschlange bleibt mit mehr Credits in Bearbeitung als ihrem Limit entspricht:
[ 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 ]---
Ab diesem Zeitpunkt ist die Credit-Zählung der CL-Warteschlange fehlerhaft, was zu einem vollständigen GPU-Hang und einer Einfrieren der Benutzeroberfläche (UI freeze) führt.
Der DRM-Scheduler bietet bereits einen Mechanismus zur Serialisierung der Timeout-Handler verschiedener Scheduler: eine geordnete Workqueue, die als `@timeout_wq`-Parameter an `drm_sched_init()` übergeben wird. Standardmäßig stellt jeder Scheduler seine Timeout-Arbeit auf der System-Workqueue bereit, was die Handler parallel ausführt. Geben Sie stattdessen allen Warteschlangen eine gemeinsame geordnete Workqueue, wie in der DRM-Scheduler-Dokumentation für Hardware mitdistinct queues (unterschiedlichen Warteschlangen) aber globalem Reset empfohlen.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.