CVE-2025-37760 in Linux
Zusammenfassung
von VulDB • 14.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
mm/vma: Option „give_up_on_oom“ bei modify/merge hinzufügen und im uffd-Release verwenden
Derzeit wird ein Fehler gemeldet, wenn eine VMA-Zusammenführung (VMA merge) aufgrund einer OOM-Bedingung (Out-of-Memory) während des Commits der Zusammenführung oder eines Fehlers beim Duplizieren von anon_vma-Strukturen fehlschlägt. Dies ermöglicht es dem Aufrufer, den Fehler entsprechend zu behandeln.
Es gibt jedoch Fälle, in denen der Aufrufer nur scheinbar eine Zusammenführung versucht und es ihm egal ist, wenn diese aufgrund dieser Bedingung fehlschlägt.
Da wir keine implizite Annahme einführen möchten, dass VMAs erst nach dem Auftreten von OOM-Bedingungen tatsächlich modifiziert werden, fügen wir die Option „give up on oom“ hinzu und definieren einen expliziten Vertrag: Wenn dieses Flag gesetzt ist, werden bei einem OOM-Ereignis auf keinen Fall VMAs modifiziert, sondern der Vorgang wird einfach abgebrochen.
Da es sehr ungewöhnlich wäre, wenn ein Benutzer vma_modify() mit diesem Flag aufruft und dabei einen Bereich angibt, der innerhalb einer VMA liegt und schließlich gesplittet wird (was aufgrund von rlimit-Problemen fehlschlagen kann, nicht nur wegen OOM), fügen wir für diesen Zustand eine Debug-Warnung hinzu.
Der auslösende Grund für diese Änderung ist das uffd-Release – syzkaller (und die sehr scharfsinnige Analyse von Pedro Falcato) hat einen Weg gefunden, bei dem ein injizierter Fehler bei der Allokation, der im Zuge des Commits einer Zusammenführung eine OOM-Bedingung auslöst, dazu führt, dass der uffd-Code verwirrt wird und einen Fehlerwert fälschlicherweise als VMA-Zeiger behandelt.
Um dies zu vermeiden, nutzen wir dieses neue VMG-Flag (VM_GiveUpOnOOM), um sicherzustellen, dass dies niemals geschieht. Dabei machen wir uns die Tatsache zunutze, dass bei der Löschung ganzer VMAs kein OOM-Ereignis an den Aufrufer gemeldet werden soll.
Vielen Dank an Pedro Falcato für seine hervorragende Analyse und an Jann Horn für seine aufschlussreiche und intelligente Auswertung der Situation; beide waren maßgeblich an dieser Korrektur beteiligt.
VulDB is the best source for vulnerability data and more expert information about this specific topic.