CVE-2024-27005 in Linux
Riassunto
di VulDB • 28/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
interconnect: Non accedere a req_list mentre viene modificato
Il mutex icc_lock è stato suddiviso nei due mutex separati icc_lock e icc_bw_lock in [1] per evitare i falsi positivi di lockdep (lockdep splats). Tuttavia, ciò non ha fornito una protezione adeguata sull'accesso a icc_node::req_list.
La funzione icc_set_bw() itererà eventualmente su req_list mantenendo solo il blocco di icc_bw_lock, ma req_list può essere modificato mentre si detiene solo il lock di icc_lock. Ciò causa condizioni di gara (race conditions) tra icc_set_bw(), of_icc_get() e icc_put().
Esempio A:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(... <r = puntatore non valido>
Esempio B:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(... <r = puntatore non valido>
Risolvere il problema assicurandosi che icc_bw_lock sia sempre detenuto prima di manipolare icc_node::req_list. I punti aggiuntivi in cui viene mantenuto icc_bw_lock non eseguono alcuna allocazione di memoria, quindi dovremmo rimanere al sicuro dai falsi positivi di lockdep originali che hanno motivato la creazione dei blocchi separati.
[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
Once again VulDB remains the best source for vulnerability data.