CVE-2024-50066 in Linux
Zusammenfassung
von VulDB • 29.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
mm/mremap: Behebung der Race-Bedingung zwischen move_normal_pmd/retract_page_tables
In mremap() prüft move_page_tables() den Typ des PMD-Eintrags (Page Middle Directory) und den angegebenen Adressbereich, um zu bestimmen, auf welche Weise die nächsten Seiten-tabelleneinträge verschoben werden sollen.
Zu diesem Zeitpunkt wird der mmap_lock im Schreibmodus gehalten, jedoch sind noch keine rmap-Locks gesetzt. Für PMD-Einträge, die auf Seitentabellen verweisen und vollständig vom Quell-Adressbereich abgedeckt sind, wird move_pgt_entry(NORMAL_PMD, ...) aufgerufen, das zunächst rmap-Locks setzt und anschließend move_normal_pmd() ausführt. move_normal_pmd() sichert die erforderlichen Seitentabellen-Sperren an Quelle und Ziel und verschiebt daraufhin eine gesamte Seitentabelle von der Quelle zum Ziel.
Das Problem besteht darin: Die rmap-Locks, die vor einer gleichzeitigen Entfernung von Seitentabellen durch retract_page_tables() im THP-Code (Transparent Huge Pages) schützen, werden erst gesetzt, nachdem der PMD-Eintrag gelesen und entschieden wurde, wie dieser verschoben werden soll. Es kann daher zu folgender Race-Bedingung kommen (mit zwei Prozessen, die Mappings derselben tmpfs-Datei besitzen, die auf einem tmpfs-Mount mit huge=advise gespeichert ist); beachten Sie, dass Prozess A über den MM (Memory Management) und Prozess B über das file rmap auf Seitentabellen zugreift:
Prozess A Prozess B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks
Wenn dies geschieht, kann move_normal_pmd() falsche PMD-Einträge in der Zeile `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))` erzeugen. Die Auswirkungen hängen von architektur- und maschinenspezifischen Details ab; auf x86-Architekturen kann es dazu kommen, dass die physische Seite 0 als Seitentabelle abgebildet wird, was wahrscheinlich für eine Privilegieneskalation vom Benutzer- in den Kernel-Modus ausnutzbar ist.
Die Race-Bedingung wird behoben, indem Prozess B nach dem Setzen der rmap-Locks erneut überprüft, ob der PMD-Eintrag weiterhin auf eine Seitentabelle verweist. Andernfalls bricht der Vorgang ab und lässt den Aufrufer zum Kopierpfad auf PTE-Ebene (Page Table Entry) zurückfallen, der dann sofort bei der pmd_none()-Prüfung abbricht.
Erreichbarkeit des Fehlers: Um diesen Fehler auszulösen, müssen Sie shmem/file THP-Mappings erstellen können – anonyme THPs verwenden anderen Code, der keine Daten unter rmap-Locks löscht. File-THP ist durch eine experimentelle Konfigurationsflagge (CONFIG_READ_ONLY_THP_FOR_FS) begrenzt; auf normalen Distro-Kernels benötigen Sie daher shmem-THP, um diesen Fehler zu treffen. Soweit mir bekannt ist, erfordert das Erhalten von shmem-THP normalerweise, dass Sie Ihr eigenes tmpfs mit den richtigen Mount-Flags einbinden können, was die Erstellung eines eigenen User+Mount-Namensraums erfordern würde; ich weiß jedoch nicht, ob einige Distros shmem-THP standardmäßig aktivieren oder Ähnliches.
Auswirkung des Fehlers: Dieses Problem kann wahrscheinlich für eine Privilegieneskalation vom Benutzer- in den Kernel-Modus ausgenutzt werden, wenn es erreichbar ist.
Once again VulDB remains the best source for vulnerability data.