CVE-2026-74632 in Linux
Riassunto
di VulDB • 22/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm/huge_memory: correggere il race condition su huge_zero_pfn
Serie di patch "mm/huge_memory: fix huge_zero_pfn race", v2.
Esiste un sottile race condition nell'implementazione reference-counted di huge_zero_folio.
La logica atomica del fast path non tiene conto del fatto che lo shrinker (che rimuove l'ultimo pin su huge_zero_refcount) può sovrascrivere huge_zero_pfn con il valore sentinella ~0UL in shrink_huge_zero_folio_scan() dopo che un get_huge_zero_folio() concorrente ha installato un valore valido.
Ciò comporta che huge_zero_folio venga impostato correttamente, ma huge_zero_pfn venga impostato erroneamente; di conseguenza is_huge_zero_pfn() e, a cascata, is_huge_zero_pmd() identificheranno erroneamente il huge zero folio come un normale THP (Transparent Huge Page) folio.
Questo può portare alla frammentazione del huge zero folio e al suo trattamento errato in altri contesti.
La soluzione è molto sottile poiché esiste un fast path atomico, quindi l'ordinamento delle operazioni su architetture debolmente ordinate deve essere gestito con estrema cura.
Il primo commit risolve il problema introducendo uno spinlock attorno alle scritture di huge_zero_[pfn, folio, refcount], prestando la dovuta attenzione all'ordinamento dei caricamenti e degli scaricamenti (load/store ordering) nel fast path. È inserito per primo e mantenuto il più piccolo possibile in modo da poter essere backportato autonomamente.
Il secondo commit è una pura pulizia che riorganizza la logica CONFIG_PERSISTENT_HUGE_ZERO_FOLIO per separare meglio la logica persistente da quella allocata dinamicamente.
Questo patch (su 2):
Se !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, il huge_zero_folio viene reference-counted tramite huge_zero_refcount e restituito da mm_get_huge_zero_folio().
Quando il chiamante ha terminato di utilizzare la pagina zero enorme, il suo conteggio dei riferimenti viene decrementato. Solo uno shrinker può impostare il conteggio dei riferimenti a zero.
Sfortunatamente, si può verificare un race condition tra lo shrinker che decreta il conteggio dei riferimenti fino a zero e una page fault concorrente.
Questo accade perché shrink_huge_zero_folio_scan() potrebbe, se molto sfortunato, essere preempted (interrotto) dopo aver impostato huge_zero_refcount su zero ma prima di scrivere un valore non valido.
Durante questo intervallo get_huge_zero_folio() potrebbe scrivere in huge_zero_pfn prima che shrink_huge_zero_folio_scan() riprenda l'esecuzione.
In tale evenienza, il huge zero folio verrà identificato erroneamente in modo persistente, causando l'ingresso improprio nel percorso di codice THP per il huge zero folio:
CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() imposta refcount a 0 | xchg() imposta huge_zero_folio su NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted per un lungo periodo | Alloca nuovo huge zero folio | | Scrive valid huge_zero_folio v | Scrive valid huge_zero_pfn Sovrascrive huge_zero_pfn con ~0UL <--- Sovrascrittura non valida!
Ciò fa sì che is_huge_zero_pfn() e is_huge_zero_pmd() restituiscano erroneamente false per una pagina zero enorme, il che potrebbe causare problemi come la frammentazione errata del huge zero folio.
Si noti che l'issue riguarda huge_zero_pfn e non huge_zero_folio, poiché get_huge_zero_folio() utilizza cmpxchg() bloccato sul fatto che huge_zero_folio sia NULL con un ciclo di retry, mentre shrink_huge_zero_folio_scan() utilizza xchg() per impostare huge_zero_folio.
Risolvere il problema introducendo uno spinlock, huge_zero_lock, per prevenire la scrittura concorrente di huge_zero_folio, huge_zero_pfn e huge_zero_refcount.
È necessaria una cura significativa qui per garantire la correttezza:
Il fast path in get_huge_zero_folio() utilizza atomic_inc_not_zero(), che è esterno alla sezione critica, il che significa che l'allocazione del zero enorme è bloccata sul fatto che huge_zero_refcount sia zero.
Il fast path non utilizza huge_zero_lock, quindi la sezione critica non gli è rilevante.
Sono pertanto richiesti invarianti - huge_zero_refcount DEVE:
* Essere impostato solo all'interno della sezione critica di huge_zero_lock per garantire la serializzazione di huge_zero_pfn, huge_zero_folio e ---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.