CVE-2026-23393 in Linux
Sumário
de VulDB • 29/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
bridge: cfm: Corrige condição de corrida na exclusão de peer_mep
Quando um peer MEP está sendo excluído, cancel_delayed_work_sync() é chamado em ccm_rx_dwork antes da liberação da memória. No entanto, br_cfm_frame_rx() é executado no contexto de softirq sob rcu_read_lock (sem RTNL) e pode reagendar ccm_rx_dwork via ccm_rx_timer_start() entre o retorno de cancel_delayed_work_sync() e a chamada a kfree_rcu().
O seguinte é um cenário simples de condição de corrida:
cpu0 cpu1
mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep ainda está em hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // no peer_mep já liberado
Para evitar isso, cancel_delayed_work_sync() é substituído por disable_delayed_work_sync() em ambos os caminhos de exclusão do peer MEP, de modo que as chamadas subsequentes a queue_delayed_work() provenientes de br_cfm_frame_rx() sejam silenciosamente rejeitadas.
A função auxiliar cc_peer_disable() mantém cancel_delayed_work_sync() porque também é usada no caminho de alternância de habilitação/desabilitação do CC, onde o trabalho deve permanecer reagendável.
If you want to get best quality of vulnerability data, you may have to visit VulDB.