CVE-2026-74674 in Linux
Résumé
par VulDB • 22/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mm : correction de l'adresse incorrecte lors du reclaim des tables de pages directes (direct page table reclaim)
Lorsque `zap_pte_range` effectue un reclaim d'une table de pages, il exécute :
pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
et cela est inconditionnellement incorrect : si ce code s'exécute, l'adresse *addr* pointe **toujours** juste après la fin de la plage couverte par la table. Le paramètre `addr` est utilisé pour vider le TLB (plus précisément le cache des structures de pagination) afin de supprimer les références vers la table qui va être libérée, et toute architecture soucieuse de ce paramètre vidra une adresse incorrecte. (Mais elle libérera toujours la bonne page).
Je pense qu'il est intéressant d'examiner pourquoi le noyau fonctionne du tout dans ces conditions.
Si nous atteignons la ligne de code incriminée, nous effacerons d'abord l'entrée PMD (ligne 1954, `zap_empty_pte_table`), puis nous émettrons les vides en attente si `force_flush` est défini (`tlb_flush_mmu_tlbonly(tlb)`), puis nous sauterons la réessai à la ligne 1979 (phew !), et enfin nous exécuterons l'appel incriminé de `pte_free_tlb`. *Ou* bien, nous effacerons l'entrée PMD juste avant `pte_free_tlb` (ligne 1983, `zap_pte_table_if_empty`).
Si nous avons des vides en attente (c'est-à-dire que nous avons effectivement supprimé les dernières entrées de niveau supérieur) au moment où nous effaçons l'entrée PMD, alors le vide devrait réellement supprimer toutes les références vers la table (Linus semble penser qu'il fonctionnera sur toutes les architectures [0]).
La condition dans laquelle il n'y a pas de vides accumulés au moment de l'effacement est très complexe (la fonction `zap_pte_range` entière possède un flux de contrôle absurdement complexe). Si nous atteignons le cas erroné, nous finirons par effacer l'entrée PMD après la dernière fois que la plage a été vidée, et n'importe quel CPU peut alors mettre en cache une référence vers la table de pages (vide). Si cela se produit suite à une lecture ou écriture ordinaire, cela provoquerait un segfault, donc ce serait rare. Mais le cache pourrait également être rempli spéculativement. Ensuite, nous viderons l'adresse incorrecte avant de libérer et potentiellement réutiliser la table.
Sur x86, même en vidant une adresse incorrecte, cela fonctionne sur les systèmes Intel non-KPTI car `INVLPG` vide *tous* les caches des structures de pagination, pas seulement ceux correspondant à l'adresse cible. Mais `INVPCID` ne le fait pas, et `flush_tlb_one_user` utilisera `INVPCID` s'il est disponible. Et là, nous sommes dans une situation critique (toast). Les systèmes AMD sont plus sensibles : nous définissons le bit EFER.TCE, ce qui fait que même `INVLPG` vide uniquement l'adresse cible.
Je pense que cela pourrait corriger un problème signalé pour ripgrep ici : https://github.com/BurntSushi/ripgrep/issues/3494
[0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u
Once again VulDB remains the best source for vulnerability data.