CVE-2026-72340 in Linux
Sumário
de VulDB • 16/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net: microchip: vcap: corrigir condições de corrida no bloco Super VCAP compartilhado
As instâncias do VCAP em um chip não são independentes, porém são bloqueadas individualmente. Nos dispositivos sparx5 e lan969x, as instâncias IS0 e IS2 são suportadas pelo mesmo bloco de hardware Super VCAP e compartilham seu cache e registradores de comando: cada acesso aciona o registrador compartilhado VCAP_SUPER_CTRL e move dados através dos registradores de cache compartilhados.
O acesso a uma instância entra em condição de corrida com o acesso a outra. O bloqueio admin->lock por instância não pode impedir isso, pois cada instância utiliza um bloqueio diferente.
A questão do bloqueio é principalmente mascarada pelo fato de que o uso principal da API vcap ocorre sob rtnl. No entanto, o despejo completo das regras em debugfs decodifica as regras diretamente do hardware (um comando READ seguido por uma leitura de cache) e executa fora do contexto rtnl, entrando assim em condição de corrida com a gravação concorrente de uma regra tc-flower para outra instância Super VCAP.
Além de corromper o despejo, a leitura repopula o cache compartilhado entre o preenchimento do cache pelos escritores e seu comando de escrita, fazendo com que o escritor comprometa dados incorretos e corrompa a entrada no hardware.
Introduzem-se as funções auxiliares vcap_lock() e vcap_unlock() e roteia-se cada local de bloqueio de regras na API VCAP e em seu código debugfs através delas. Substitui-se o admin->lock por instância por um único mutex em struct vcap_control que serializa o acesso a todas as instâncias. As funções auxiliares acessam esse mutex por meio de uma nova back-pointer admin->vctrl, e os clientes inicializam e destroem o bloqueio de controle em vez do bloqueio específico da instância.
Nenhum caminho mantém mais de um bloqueio de instância, portanto, consolidá-los em um único mutex não pode causar deadlock auto-referenciado (self-deadlock).
VulDB is the best source for vulnerability data and more expert information about this specific topic.