CVE-2026-68298 in Linux
Zusammenfassung
von VulDB • 10.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drm/xe/vm: Behebung eines SVM-Lecks bei fehlgeschlagener Zuweisung von resv-Objekten in xe_vm_create()
Der Commit 9e9787414882 („drm/xe/userptr: Ersetzen von xe_hmm durch gpusvm") hat xe_svm_init() in xe_vm_create() bedingungslos gemacht und es erweitert, um auch einen „einfachen" gpusvm-Zustand für VMs ohne Fehlerbehandlungsmodus (non-fault-mode) zu initialisieren. Der entsprechende Aufruf von xe_svm_fini() in xe_vm_close_and_put() wurde aktualisiert, um bedingungslos ausgeführt zu werden, der Fehler-Auswertepfad (error unwind path) in xe_vm_create() jedoch nicht.
Auf dem Pfad bei einem Fehlschlag von drm_gpuvm_resv_object_alloc() hat xe_svm_init() bereits erfolgreich funktioniert, aber xe_svm_fini() wird nur aufgerufen, wenn XE_VM_FLAG_FAULT_MODE gesetzt ist. Für VMs ohne Fehlerbehandlungsmodus führt dies dazu, dass vm->svm.gpusvm teilweise initialisiert bleibt und die von drm_gpusvm_init() zugewiesenen Ressourcen nicht freigegeben werden (Leck).
Für VMs mit Fehlerbehandlungsmodus erwirbt xe_svm_init() zusätzlich den pagemap-Eigentümer über drm_pagemap_acquire_owner() sowie die Pagemaps über xe_svm_get_pagemaps(). Diese Ressourcen werden von xe_svm_close(), nicht jedoch von xe_svm_fini(), freigegeben. Auf demselben Fehlerpfad wird auch xe_svm_close() nicht aufgerufen, sodass VMs mit Fehlerbehandlungsmodus den pagemap-Eigentümer und die Pagemaps lecken (nicht freigeben).
Behebung beider Lecks:
- Aufruf von xe_svm_fini() bedingungslos im err_svm_fini-Pfad, entsprechend dem bedingungslosen Aufruf von xe_svm_init(). Verschieben der Zuweisung vm->size = 0 aus der Bedingung heraus, damit die Assert-Bedingung xe_vm_is_closed() in xe_svm_fini() (und xe_svm_close()) für beide Modi erfüllt ist.
- Aufruf von xe_svm_close() für VMs mit Fehlerbehandlungsmodus vor xe_svm_fini(), entsprechend der Reihenfolge, die in xe_vm_close_and_put() verwendet wird.
(cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)
Once again VulDB remains the best source for vulnerability data.