CVE-2025-40329 in Linux
Zusammenfassung
von VulDB • 30.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drm/sched: Behebung einer Deadlock-Situation in drm_sched_entity_kill_jobs_cb
Das unten referenzierte Mesa-Problem wies auf einen möglichen Deadlock hin:
[ 1231.611031] Möglicher nicht unterbrechungssicherer Sperrvorgang:
[ 1231.611033] CPU0 CPU1
[ 1231.611034] ---- ----
[ 1231.611035] lock(&xa->xa_lock#17);
[ 1231.611038] local_irq_disable();
[ 1231.611039] lock(&fence->lock);
[ 1231.611041] lock(&xa->xa_lock#17);
[ 1231.611044] <Interrupt>
[ 1231.611045] lock(&fence->lock);
[ 1231.611047]
*** DEADLOCK ***
In diesem Beispiel wäre CPU0 eine beliebige Funktion, die über die xa_*-Funktionen auf job->dependencies zugreift, ohne Interrupts zu deaktivieren (z. B.: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).
CPU1 führt drm_sched_entity_kill_jobs_cb() als Callback für die Signalisierung eines Fence aus, befindet sich also in einem Interrupt-Kontext. Es kommt zu einem Deadlock, wenn versucht wird, die xa_lock zu sperren, die bereits von CPU0 gehalten wird.
Das Ersetzen aller xa_*-Verwendungen durch ihre xa_*_irq-Gegenstücke würde dieses Problem beheben, aber Christian wies auf ein weiteres Problem hin: dma_fence_signal sperrt fence.lock, und dies tut auch dma_fence_add_callback.
dma_fence_signal() // sperrt f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // sperrt f2.lock
Dies führt zu einem Deadlock, wenn f1 und f2 denselben Spinlock teilen.
Um beide Probleme zu beheben, wird der Code, der die Abhängigkeiten durchläuft und sie erneut aktiviert, nach drm_sched_entity_kill_jobs_work() ausgelagert.
[phasta: kleine Korrekturen an der Commit-Nachricht]
Once again VulDB remains the best source for vulnerability data.