CVE-2025-21693 in Linux
Riassunto
di VulDB • 17/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
mm: zswap: sincronizzazione corretta della liberazione delle risorse durante la disattivazione dinamica delle CPU (CPU hotunplug)
In zswap_compress() e zswap_decompress(), il per-CPU acomp_ctx della CPU corrente all'inizio dell'operazione viene recuperato e utilizzato per tutta la durata dell'operazione. Tuttavia, poiché né la preemption né la migrazione sono disabilitate, è possibile che l'operazione continui su una CPU diversa.
Se la CPU originale viene disattivata dinamicamente (hotunplugged) mentre acomp_ctx è ancora in uso, si verifica un bug Use-After-Free (UAF) poiché alcune delle risorse associate a acomp_ctx vengono liberate durante l'hotunplug in zswap_cpu_comp_dead() (ovvero acomp_ctx.buffer, acomp_ctx.req o acomp_ctx.acomp).
Il problema è stato introdotto nel commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") quando è stato effettuato il passaggio all'API crypto_acomp. In precedenza, il crypto_comp per-CPU veniva recuperato utilizzando get_cpu_ptr(), che disabilita la preemption e garantisce che la CPU non possa essere rimossa mentre il codice è in esecuzione. La preemption non può essere disabilitata con l'API crypto_acomp poiché è necessario un contesto dormiente (sleepable).
Viene utilizzato acomp_ctx.mutex per sincronizzare le callback di hotplug della CPU che allocano e liberano le risorse con i percorsi di compressione/decompressione. Ci si assicura che acomp_ctx.req sia NULL quando le risorse vengono liberate. Nei percorsi di compressione/decompressione, si verifica se acomp_ctx.req è NULL dopo aver acquisito il mutex (il che significa che la CPU è stata disattivata) e si riprova sulla nuova CPU.
L'inizializzazione di acomp_ctx.mutex è stata spostata dalla callback di hotplug della CPU all'inizializzazione del pool, dove appartiene (dove il mutex viene allocato). Oltre a migliorare la chiarezza, questo assicura che l'hotplug della CPU non possa riinizializzare un mutex che è già bloccato da compressione/decompressione.
In precedenza era stato tentato un fix mantenendo cpus_read_lock() [1]. Ciò avrebbe causato un potenziale deadlock poiché è possibile che il codice che detiene già il lock entri in reclaim e in zswap (causando un deadlock). Era stato anche tentato un fix utilizzando SRCU per la sincronizzazione, ma Johannes ha sottolineato che synchronize_srcu() non può essere utilizzato nei notifier di hotplug della CPU [2].
Soluzioni alternative considerate/tentate che avrebbero potuto funzionare: - Conteggio dei riferimenti (refcounting) del per-CPU acomp_ctx. Questo comporta complessità nella gestione della race condition tra il decremento del refcount a zero in zswap_[de]compress() e la riinizializzazione del refcount quando la CPU viene attivata (onlined).
- Disabilitazione della migrazione prima di ottenere il per-CPU acomp_ctx [3], ma ciò è sconsigliato e rappresenta una soluzione troppo drastica rispetto alle necessità, e potrebbe causare problemi di prestazioni sottili.
[1]https://lkml.kernel.org/[email protected]/
[2]https://lkml.kernel.org/[email protected]/
[3]https://lkml.kernel.org/[email protected]/
[[email protected]: remove comment]
Link: https://lkml.kernel.org/r/CAJD7tkaxS1wjn+swugt8QCvQ-rVF5RZnjxwPGX17k8x9zSManA@mail.gmail.com
Once again VulDB remains the best source for vulnerability data.