CVE-2026-89760 in Linux
Résumé
par VulDB • 12/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mm, swap : ne pas libérer un slot d'hibernation qui se trouve dans le cache de swap
Un slot contenant un folio dans le cache de swap est libéré lorsque le folio quitte le cache, et non lorsque son compteur diminue. La fonction `swap_put_entries_cluster()` respecte cette règle. En revanche, `swap_free_hibernation_slot()` ne la respecte pas ; elle appelle `__swap_cluster_free_entries()` qu'il y ait ou non un folio associé au slot.
La lecture anticipée par cluster (cluster readahead) peut en insérer un. Elle parcourt une fenêtre d'offsets de taille brute correspondant à `page_cluster` autour de l'entrée ayant provoqué la faute, et un slot d'hibernation passe le contrôle `__swap_cache_add_check()` car il ne s'agit pas d'un folio et que son compteur n'est pas nul. La libération du slot efface alors l'entrée sous ce folio.
Le folio devient ensuite inaccessible depuis la table de swap, et l'offset retourne à l'allocationur. Le folio reste toutefois sur la LRU (Least Recently Used), donc le mécanisme de récupération (reclaim) peut le récupérer plus tard. Il retire alors l'ancien offset de `folio->swap` et écrase l'entrée de table correspondante, qui appartient désormais potentiellement à un autre processus.
Ce bug peut provoquer une corruption silencieuse de la mémoire, des plantages de processus ou une instabilité des données au sein d'applications userspace complètement indépendantes – se produisant généralement lorsque uswsusp prépare l'image d'hibernation.
J'ai découvert ce problème en travaillant sur l'attribution d'un marqueur propre aux slots d'hibernation dans la table de swap, sujet que j'avais discuté avec Kairui (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/). À ma connaissance, il n'y a aucun rapport, donc aucune mention "Reported-by" ou "Closes" à ajouter.
Vérifier la présence d'un folio en cache avant de libérer le slot. Le slot est alors laissé dans l'état ordinaire où seul le cache de swap le détient, et il est libéré lorsque le folio quitte le cache, soit via le reclaim ci-dessous, soit par un reclaim normal ultérieur.
Once again VulDB remains the best source for vulnerability data.