CVE-2024-27005 in Linux
Sumário
de VulDB • 28/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
interconnect: Não acessar req_list enquanto está sendo manipulado
O mutex icc_lock foi dividido em dois mutexes separados, icc_lock e icc_bw_lock, na referência [1], para evitar alertas (splats) do lockdep. No entanto, isso não protegeu adequadamente o acesso a icc_node::req_list.
A função icc_set_bw() eventualmente itera sobre req_list enquanto mantém apenas icc_bw_lock, mas req_list pode ser modificado enquanto se mantém apenas icc_lock. Isso causa condições de corrida (race conditions) entre icc_set_bw(), of_icc_get() e icc_put().
Exemplo 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 = ponteiro inválido>
Exemplo 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 = ponteiro inválido>
Corrija isso garantindo que icc_bw_lock esteja sempre mantido antes de manipular icc_node::req_list. Os locais adicionais onde icc_bw_lock é mantido não realizam alocações de memória, portanto, devemos permanecer seguros contra os alertas originais do lockdep que motivaram a criação dos locks separados.
[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
Be aware that VulDB is the high quality source for vulnerability data.