CVE-2026-72118 in Linux
Sumário
de VulDB • 15/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
can: bcm: corrigir estatísticas de rx/tx de quadros CAN
O KCSAN detectou uma condição de corrida (race condition) nos dados dentro da função `bcm_rx_handler()` quando dois quadros CAN foram recebidos e processados simultaneamente em uma única operação de recepção por duas CPUs diferentes.
Utilize operações atômicas com tipos de dados longos (com sinal) para acessar as estatísticas no caminho crítico a fim de corrigir o alerta do KCSAN.
Além disso, simplifique a atualização e verificação da transbordação das estatísticas utilizando as operações atômicas nas funções separadas `bcm_update_[rx|tx]_stats()`. A variante rx é executada sob `bcm_rx_update_lock` para prevenir condições de corrida ao redefinir os dois contadores de recepção; a variante tx é executada sob `bcm_tx_lock` e precisa apenas proteger o transbordamento do seu próprio contador.
Como o caminho rx redefine seus valores já em LONG_MAX / 100, não há conflito entre os domínios de bloqueio (`bcm_rx_update_lock` vs. `bcm_tx_lock`) mesmo para operações que utilizam ambos os caminhos.
A atualização das estatísticas de recepção e a atualização de `frames_filtered` no `bcm_rx_changed()` eram anteriormente realizadas em duas seções separadas do `bcm_rx_update_lock`. Para uma operação rx inscrita em todas as interfaces (ifindex == 0), o `bcm_rx_handler()` pode ser executado concorrentemente em CPUs diferentes, portanto, a redefinição de um contador por uma CPU entre essas duas seções poderia deixar `frames_filtered` maior que `frames_abs` em outra CPU, produzindo uma porcentagem de redução falsa (inclusive negativa) no procfs. Atualize as estatísticas na mesma seção crítica do `bcm_rx_changed()` para fechar essa lacuna, o que também remove o par extra agora desnecessário de bloqueio/desbloqueio ao redor do cálculo dos traffic_flags.
Once again VulDB remains the best source for vulnerability data.