CVE-2025-38334 in Linux
Résumé
par VulDB • 01/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
x86/sgx : Empêcher les tentatives de récupération des pages corrompues (poisoned)
TL;DR : La récupération des pages SGX accède à la page pour copier son contenu vers un stockage secondaire. Les instructions SGX ne gèrent pas correctement les vérifications matérielles (machine checks). Malgré cela, le code SGX existant tentera de récupérer des pages qu’il _sait_ être corrompues. Éviter même d’essayer de récupérer ces pages corrompues.
L’explication détaillée :
Les pages utilisées par une enclave ont uniquement leur champ `epc_page->poison` défini dans `arch_memory_failure()`, mais elles restent sur la liste `sgx_active_page_list` jusqu’à l’appel de `sgx_encl_release()`, avec le drapeau `SGX_EPC_PAGE_RECLAIMER_TRACKED` inchangé.
La valeur `epc_page->poison` n’est pas vérifiée dans la logique du récupérateur (reclaimer), ce qui signifie que, si les autres conditions sont remplies, une tentative sera faite pour récupérer une page EPC qui a été corrompue. Cela est problématique car 1. nous ne voulons pas que cette page finisse par être ajoutée à une autre enclave et 2. cela risque de provoquer l’arrêt d’un cœur (core) et un panic du noyau.
Plus précisément, la récupération utilise des opérations microprogrammées incluant « EWB », qui accèdent au contenu de la page EPC pour le chiffrer et l’écrire dans une mémoire non-SGX. Ces opérations ne peuvent pas gérer les MCE (Machine Check Exceptions) lors de leurs accès autrement qu’en plaçant le cœur d’exécution dans un état d’arrêt spécial (affectant à la fois les deux threads avec HT). Le noyau provoquera ensuite un panic sur les cœurs restants, constatant que le cœur n’a pas entré dans le(s) gestionnaire(s) MCE à temps.
Appeler `sgx_unmark_page_reclaimable()` permet de retirer la page EPC concernée de `sgx_active_page_list` en cas d’erreur mémoire pour empêcher qu’elle ne soit considérée comme récupérable.
Tester `epc_page->poison` dans `sgx_reclaim_pages()` fonctionnerait également, mais il est supposé préférable d’ajouter du code dans les chemins de moindre probabilité.
La page EPC concernée n’est pas ajoutée à `&node->sgx_poison_page_list` plus tardivement dans `sgx_encl_release()->sgx_free_epc_page()` lorsqu’elle est retirée (EREVMOVED). L’appartenance aux autres listes ne change pas afin d’éviter de modifier la sémantique des listes, sauf pour `sgx_active_page_list`. Il existe un commentaire « TBD » dans `arch_memory_failure()` concernant les actions préventives ; l’objectif ici n’est pas de traiter tout ce que cela pourrait impliquer.
Cela ne ferme pas non plus complètement la fenêtre temporelle durant laquelle une notification d’erreur mémoire sera fatale (pour une page EPC précédemment saine) — le MCE peut survenir après que `sgx_reclaim_pages()` a sélectionné ses candidats ou même *à l’intérieur* d’une opération microprogrammée (en fait facile à déclencher en raison du temps passé dans ces opérations).
Le spinlock dans `sgx_unmark_page_reclaimable()` est sûr car `memory_failure()` s’exécute dans un contexte processus et aucun spinlock n’est détenu, comme explicitement noté dans le commentaire de `mm/memory-failure.c`.
Once again VulDB remains the best source for vulnerability data.