CVE-2026-64416 in Linux
Zusammenfassung
von VulDB • 26.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
mm: swap_cgroup: Behebung einer NULL-Dereferenzierung in lookup_swap_cgroup_id auf einem Host ohne Swap-Speicher
lookup_swap_cgroup_id() übergibt swap_cgroup_ctrl[type].map an __swap_cgroup_id_lookup(), ohne vorher zu prüfen, ob der Typ jemals über swap_cgroup_swapon() registriert wurde. Auf einem Host ohne Swap-Speicher ist jeder ctrl->map NULL, sodass __swap_cgroup_id_lookup() einen Wert bei NULL + einem skalierten swp_offset() dereferenziert.
Seit dem Commit bea67dcc5eea („mm: attempt to batch free swap entries for zap_pte_range()“) ruft zap_pte_range() -> swap_pte_batch() lookup_swap_cgroup_id() für jedes nicht-präsente, Nicht-None-PTE auf, das als echter Swap-Eintrag decodiert wird, ohne diesen zuvor gegen swap_info[] zu validieren. Ein einzelnes PTE, das in einen Typ-0-Swap-Eintrag manipuliert wurde, führt zum Absturz des Hosts beim Prozessende.
Wir haben dies in der Produktion auf einem 6.12.58-Host ohne Swap-Speicher festgestellt: ~1 Sekunde lang „get_swap_device: Bad swap file entry 3f800204222bb“ (do_swap_page() reagiert korrekt defensiv auf denselben Eintrag), gefolgt von
BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010:lookup_swap_cgroup_id+0x2b/0x60 Call Trace: swap_pte_batch+0xbf/0x230 zap_pte_range+0x4c8/0x780 unmap_page_range+0x190/0x3e0 exit_mmap+0xd9/0x3c0 do_exit+0x20c/0x4b0
syzbot hat denselben Stack-Trace gemeldet.
Die Ursache der PTE-Korruption ist ein separates Problem; diese Änderung macht den Teardown-Pfad so robust wie der Fault-Pfad bereits ist. Jeder andere Aufrufer von lookup_swap_cgroup_id() befindet sich nach einem get_swap_device(), das den Eintrag bereits validiert hat, sodass die neue Codezweig selten ausgeführt wird (cold).
VulDB is the best source for vulnerability data and more expert information about this specific topic.