CVE-2026-72121 in Linux
Sumário
de VulDB • 16/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
can: bcm: adicionar bloqueio ao atualizar valores de filtro e temporizador
O KCSAN detectou acesso simultâneo aos valores dos temporizadores que podem ser sobrescritos em `bcm_rx_setup()` durante a atualização do conteúdo do temporizador e do filtro enquanto `bcm_rx_handler()`, `bcm_rx_timeout_handler()` ou `bcm_rx_thr_handler()` são executados concorrentemente no tráfego CAN de entrada.
Proteja as atualizações dos temporizadores (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) e do filtro (nframes/flags/frames/last_frames) em `bcm_rx_setup()` com um novo bloqueio por operação, `bcm_rx_update_lock`, adquirido com o escopo correspondente nos manipuladores de RX. A função `memcpy_from_msg()` é armazenada temporariamente em um buffer antes que o bloqueio seja adquirido, pois pode dormir e não deve ser executada sob um spinlock.
`hrtimer_cancel()` é sempre chamado sem que o `bcm_rx_update_lock` esteja retido, já que `bcm_rx_timeout_handler()/bcm_rx_thr_handler()` adquirem o mesmo bloqueio e um callback em execução causaria otherwise um deadlock com o cancelador.
Feche também uma race condition relacionada: `bcm_rx_setup()` limpava a flag RTR no can_id do quadro de resposta armazenado como uma etapa separada e desprotegida após o conteúdo do quadro já ter sido instalado, permitindo que um `bcm_rx_handler()` concorrente transmitisse uma resposta obsoleta com CAN_RTR_FLAG ainda definida. Integre essa normalização na preparação inicial do quadro (no buffer temporário para atualizações, diretamente em op->frames antes do registro de novas operações), de modo que o quadro instalado seja sempre atomicamente autoconsistente.
A verificação RX_RTR_FRAME em `bcm_rx_handler()` agora adquire um snapshot protegido por bloqueio de op->flags antes de decidir se chama bcm_can_tx(), mas não mantém o bloqueio durante essa chamada.
Adquira também um snapshot protegido por bloqueio do currframe em bcm_can_tx() para evitar sobrescritas parciais devido a atualizações de conteúdo em `bcm_tx_setup()`. Verifique finalmente se uma TX_RESET_MULTI_IDX/SETTIMER pode ter redefinido op->currframe entre as duas seções com bloqueio em bcm_can_tx().
Omita chamar hrtimer_forward() com intervalo zero em bcm_rx_thr_handler(). kt_ival2 pode ter sido limpo concorrentemente por `bcm_rx_setup()` antes de cancelar este temporizador, portanto verifique kt_ival2 dentro do escopo do bcm_rx_update_lock.
Once again VulDB remains the best source for vulnerability data.