CVE-2024-53068 in Linux
Riassunto
di VulDB • 15/06/2026
Nel kernel Linux, è stata rilevata una **Use-After-Free (UAF)** o un **Double-Free** nell'algoritmo di gestione dei dispositivi SCMI (System Control and Management Interface).
### Analisi dello Stack Trace
1. **Allocazione (Allocated by task 1):** * La memoria viene allocata tramite `kstrdup` -> `__scmi_device_create` -> `scmi_chan_setup` -> `scmi_probe`. * Questo avviene durante la fase di inizializzazione del driver SCMI (`scmi_driver_init`).
2. **Deallocazione (Freed by task 1):** * La stessa memoria viene liberata tramite `kfree_const` -> `__scmi_device_destroy` -> `scmi_chan_setup` -> `scmi_probe`. * Nota importante: **Sia l'allocazione che la deallocazione avvengono nello stesso thread (task 1) e durante la stessa chiamata a `scmi_probe`**.
3. **Il Problema:** * Lo stack trace mostra che `scmi_chan_setup` chiama sia `scmi_device_create` (che alloca) che `scmi_device_destroy` (che libera). * Se `scmi_chan_setup` fallisce dopo l'allocazione ma prima del completamento, o se c'è un percorso di errore che porta alla distruzione, la memoria viene liberata. * Tuttavia, il report KASAN indica che la memoria è stata **già liberata** e poi **riutilizzata** (o liberata di nuovo), il che suggerisce che il puntatore alla struttura allocata non è stato impostato a `NULL` dopo la liberazione, oppure che la struttura viene liberata due volte in percorsi di errore diversi.
### Possibili Cause
1. **Mancanza di `NULL` dopo `kfree`:** Dopo `kfree_const(ptr)`, il puntatore `ptr` non viene impostato a `NULL`. Se il codice tenta di accedere a `ptr` o di liberarlo di nuovo, si verifica un UAF o Double-Free.
2. **Percorsi di Errore in `scmi_chan_setup`:** La funzione `scmi_chan_setup` potrebbe avere più punti di uscita. Se un errore si verifica dopo l'allocazione ma prima che il puntatore venga salvato in modo sicuro, o se la distruzione viene chiamata più volte, si verifica il bug.
3. **Concorrenza (meno probabile qui):** Poiché tutto avviene in `task 1` durante `scmi_probe`, la concorrenza non è la causa diretta. È un bug di logica nel driver.
### Soluzione Consigliata
1. **Impostare a `NULL` dopo la liberazione:** Assicurarsi che dopo ogni `kfree` o `kfree_const`, il puntatore corrispondente venga impostato a `NULL`.
```c kfree_const(ptr); ptr = NULL; ```
2. **Verificare i Percorsi di Errore in `scmi_chan_setup`:** Controllare la funzione `scmi_chan_setup` nel codice sorgente del driver SCMI. Assicurarsi che: * La distruzione (`scmi_device_destroy`) venga chiamata solo una volta. * Non ci siano percorsi di errore che portano a una doppia liberazione. * Il puntatore alla struttura allocata venga salvato in un luogo sicuro prima di eventuali chiamate di errore.
3. **Aggiornare il Driver:** Se questo bug è stato già segnalato e corretto in una versione più recente del kernel, aggiornare il kernel.
### Esempio di Correzione (Pseudocodice)
```c int scmi_chan_setup(...) {
struct scmi_device *dev; int ret;
dev = scmi_device_create(...); if (!dev) return -ENOMEM;
// ... configurazione ...
if (error_condition) {
scmi_device_destroy(dev); dev = NULL; // Importante: impostare a NULL return -EINVAL; }
// ... successo ... return 0; } ```
### Conclusione
Il bug è un **Use-After-Free** o **Double-Free** nel driver SCMI, causato da una gestione errata della memoria durante la fase di inizializzazione (`scmi_probe`). La correzione richiede di assicurarsi che la memoria venga liberata una sola volta e che i puntatori vengano impostati a `NULL` dopo la liberazione.
If you want to get best quality of vulnerability data, you may have to visit VulDB.