CVE-2026-80893 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mm/hugetlb : correction de la corruption des entrées d'échange (swap) lors de l'effacement du bit uffd-wp dans fork()
La fonction `copy_hugetlb_page_range()` efface le bit uffd-wp des entrées de migration et de hwpoison à l'aide de `huge_pte_clear_uffd_wp()`, qui opère sur la position du bit PTE présent (present-PTE). Les entrées d'échange conservent l'état uffd-wp ailleurs ; la branche de lecture définit ce bit avec `pte_swp_uffd_wp()` et `pte_swp_mkuffd_wp()`. La position du bit PTE présent tombe dans le payload de l'entrée swap. Sur x86-64, elle se situe dans l'inversement (inverted) du décalage d'échange (swap offset), où un PFN hugetlb naturellement aligné a toujours ce bit affecté défini ; par conséquent, l'effacement avance le PFN encodé de deux pages.
Aucun utilisateur de userfaultfd n'a besoin d'être impliqué : l'effacement est protégé uniquement par le fait que la VMA (Virtual Memory Area) de l'enfant n'est pas enregistrée avec uffd-wp, donc un simple `fork()` avec une entrée de migration hugetlb en cours d'exécution (ou une page hugetlb empoisonnée/hwpoisoned) corrompt l'entrée copiée dans le processus enfant. L'instrumentation de l'effacement et du fork après un appel MADV_HWPOISON sur une page hugetlb anonyme de 2 Mo montre :
offset avant = 120e00 offset après = 120e02
Les conséquences sont principalement latentes : les parcours rmap correspondent aux entrées de migration par plage de folio, et `remove_migration_pte()` reconstruit le PTE à partir du folio ; ainsi, un décalage (skew) de PFN au sein d'un folio se répare une fois la migration terminée. Cependant, tout chemin qui ré-encode l'offset corrompu — par exemple `hugetlb_change_protection()` réécrivant une entrée de migration writable via `make_readable_migration_entry(swp_offset(entry))` — le propage.
Les entrées de migration portent légitimement uffd-wp ; il faut donc les effacer avec `pte_swp_clear_uffd_wp()`, en cohérence avec `copy_nonpresent_pte()` et `move_huge_pte()`.
Une entrée hwpoison, d'autre part, ne porte jamais le bit uffd-wp : elle est installée fraîchement par `make_hwpoison_entry()` (`try_to_unmap_one()` ne conserve pas uffd-wp sur le chemin hwpoison) et `hugetlb_change_protection()` laisse les entrées hwpoison intactes. Il n'y avait donc rien à effacer, seulement la corruption ; il faut donc supprimer l'effacement complètement.
If you want to get best quality of vulnerability data, you may have to visit VulDB.