CVE-2024-53071 in Linuxinfo

Zusammenfassung

von VulDB • 26.05.2026

Im Linux-Kernel wurde folgende Schwachstelle behoben:

drm/panthor: Strengere Prüfung der IO-Mapping-Flags

Die aktuelle Implementierung von panthor_device_mmap_io() weist zwei Probleme auf:

1. Beim Mappen von DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET bricht panthor_device_mmap_io() ab, wenn VM_WRITE gesetzt ist, löscht jedoch VM_MAYWRITE nicht. Das bedeutet, dass der Benutzerbereich (Userspace) mprotect() verwenden kann, um das Mapping später schreibbar zu machen. Dies ist ein klassisches Problem bei Linux-Treibern. Ich glaube nicht, dass dies in der Praxis tatsächlich Auswirkungen hat: Wenn die GPU eingeschaltet ist, werden Schreibzugriffe auf die FLUSH_ID anscheinend ignoriert; und wenn die GPU nicht eingeschaltet ist, ist die vom Treiber bereitgestellte dummy_latest_flush-Seite absichtlich so konzipiert, dass sie keine Flushes ausführt, sodass das einzige, was das Schreiben in die dummy_latest_flush bewirken könnte, darin bestehen würde, *mehr* Flushes auszulösen.

2. panthor_device_mmap_io() blockiert keine MAP_PRIVATE-Mappings (das sind Mappings ohne das VM_SHARED-Flag). MAP_PRIVATE in Kombination mit VM_MAYWRITE zeigt an, dass die VMA Copy-on-Write-Semantik aufweist, was für VM_PFNMAP nur teilweise unterstützt wird und als ziemlich problematisch gilt. Insbesondere kann der Treiber in einem solchen Mapping PTEs nur während mmap() durch Aufruf von remap_pfn_range() installieren (da remap_pfn_range() **die physische Adresse des gemappten physischen Speichers in der vm_pgoff der VMA speichern möchte**); das spätere Installieren von PTEs mit einem Fault-Handler (wie panthor es tut) wird in privaten Mappings nicht unterstützt, und wenn Sie versuchen, ein solches Mapping zu faulten, löst vmf_insert_pfn_prot() einen Fehler aus, wenn es eine BUG()-Prüfung trifft.

Beheben Sie dies, indem Sie das VM_MAYWRITE-Flag löschen (das Schreiben des Benutzerbereichs in die FLUSH_ID ergibt keinen Sinn) und VM_SHARED erzwingen (Copy-on-Write-Semantik für die FLUSH_ID ergibt keinen Sinn).

Reproducer für beide Szenarien befinden sich in den Hinweisen zu meinem Patch auf der Mailingliste; ich habe getestet, dass diese Bugs auf einem Rock 5B-System vorhanden sind.

Beachten Sie, dass ich den Patch nur kompiliert getestet habe, ihn aber nicht ausgeführt habe; ich habe noch keine funktionierende Kernel-Build-Umgebung für das Testsystem. Bitte testen Sie ihn, bevor Sie ihn anwenden.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Zuständig

Linux

Reservieren

19.11.2024

Veröffentlichung

19.11.2024

Moderieren

akzeptiert

Eintrag

VDB-285326

CPE

bereit

EPSS

0.00196

KEV

nein

Aktivitäten

very low

Quellen

Interested in the pricing of exploits?

See the underground prices here!