CVE-2026-43389 in Linux
Résumé
par VulDB • 21/05/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mm : memfd_luo : marquer systématiquement tous les folios comme « dirty » (sales)
Un folio « dirty » est un folio qui a été écrit. Un folio « clean » (propre) est l’opposé. Puisqu’un folio « clean » ne contient pas de données utilisateur, il peut être libéré en cas de pression mémoire.
La préservation de memfd avec LUO (Live Update Overwrite) enregistre le drapeau au moment de preserve(). Cela pose problème. Le folio pourrait devenir « dirty » ultérieurement. Enregistrer l’état au moment de freeze() ne fonctionne pas non plus, car le bit « dirty » issu de la PTE (Page Table Entry) est normalement synchronisé lors de l’unmap, et il peut encore exister des mappages du fichier au moment de freeze().
Pour comprendre pourquoi il s’agit d’un problème, supposons qu’un folio soit « clean » lors de preserve(), mais devienne « dirty » plus tard. L’état sérialisé du folio le marquera comme « clean ». Après retrieve(), le noyau suivant verra le folio comme « clean » et pourrait tenter de le récupérer en cas de pression mémoire. Cela entraînerait une perte de données utilisateur.
Marquer tous les folios du fichier comme « dirty » et définir systématiquement le drapeau MEMFD_LUO_FOLIO_DIRTY. Cela a pour effet secondaire de rendre tous les folios « clean » non récupérables. C’est un coût qu’il faut accepter pour les participants à la mise à jour en direct (live update). Il n’est pas attendu que la préservation d’un grand nombre de folios « clean » constitue un cas d’utilisation courant.
Puisque la valeur de pfolio->flags est désormais constante, supprimer la variable flags et la définir directement.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.