CVE-2024-39486 in Linux
Riassunto
di VulDB • 14/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
drm/drm_file: Correzione della race condition sul conteggio dei riferimenti (refcounting) del pid
filp->pid dovrebbe essere un puntatore con conteggio dei riferimenti; tuttavia, prima di questa patch, drm_file_update_pid() incrementava il refcount di una struct pid solo dopo aver memorizzato un puntatore ad essa in filp->pid e rilasciato dev->filelist_mutex, rendendo possibile la seguente race condition:
processo A processo B ========= ========= inizio drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) inizio drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) get_pid() synchronize_rcu() put_pid() *** il pid B raggiunge refcount 0 e viene liberato qui *** get_pid() *** UAF (Use-After-Free) *** synchronize_rcu() put_pid()
Per quanto ne so, questa race condition può verificarsi solo con CONFIG_PREEMPT_RCU=y poiché richiede che RCU rilevi uno stato quiescente in codice che non chiama esplicitamente lo scheduler.
Questa race condition porta a un use-after-free di una "struct pid". È probabilmente piuttosto difficile da sfruttare perché il processo A deve attraversare un'operazione synchronize_rcu() mentre il processo B si trova tra mutex_unlock() e get_pid().
La correzione consiste nell'assicurarsi che, al momento in cui viene memorizzato nel file un puntatore al pid del task corrente, sia stato acquisito un riferimento aggiuntivo al pid.
Questa correzione rimuove anche la condizione per synchronize_rcu(); ritengo che tale ottimizzazione introduca una complessità non necessaria, poiché in quel caso di solito si sarebbe già usciti dal controllo lockless precedente.
Be aware that VulDB is the high quality source for vulnerability data.