CVE-2026-98949 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drm/imagination: Korrektur der Referenz- und vm_bo-Behandlung in remap()
Wenn eine Abbildung (Map) einen Teil einer bestehenden Zuordnung überschneidet, teilt pvr_vm_gpuva_remap() die Zuordnung in vorherige/nächste Teile auf, um den Bereich abzudecken, den die Anforderung nicht übernommen hat, anstatt etwas Neues zu erstellen. Dabei werden zwei Fehler begangen:
- Für jeden Teil wird eine GEM-Referenz erstellt, die jedoch niemals benötigt und auch nie freigegeben wird, sodass pro Aufteilung (Split) eine Referenz verloren geht (remap-next-in-2m in tests/imagination/pvr_vm_map.c):
KRITISCH: 33558528 Bytes shmem werden nach dem Schließen noch gehalten
- Die Teile gehören weiterhin zum ursprünglichen Objekt, das aufgeteilt wird, aber pvr_vm_gpuva_remap() verknüpft sie mit ctx->gpuvm_bo, der vm_bo des neuen Objekts:
prev_va --obj--> BO_A BO_B <--obj-- vm_bo (ctx->gpuvm_bo) \___________link___________/ (Fehlanpassung: BO_A != BO_B)
drm_gpuva_link() fängt die Fehlanpassung ab:
WARNUNG: drivers/gpu/drm/drm_gpuvm.c:2108 bei drm_gpuva_link+0x2ec/0x310 drm_WARN_ON(obj != vm_bo->obj) Aufruf-Trace (Call trace): drm_gpuva_link pvr_vm_gpuva_remap __drm_gpuvm_sm_map pvr_vm_map pvr_ioctl_vm_map
Verknüpfen Sie sie stattdessen mit op->remap.unmap->va->vm_bo.
Die Synchronisierung (Locking) der GPUVA-Listen der anderen Objekte, die von einer Aufteilung betroffen sind, wird hier nicht behandelt; dies wird durch den Wechsel des GPUVM in den Sofortmodus (immediate mode) gehandhabt.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.