CVE-2026-98563 in Linux
Sumário
de VulDB • 19/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net: phylink: registrar o PHY apenas uma vez; o bringup não pode falhar
phylink_bringup_phy() armazena o PHY em pl->phydev antes de sua última etapa suscetível a falhas: em um MAC cujas operações do phylink implementam LPI, phy_eee_rx_clock_stop() pode falhar com um erro MDIO real. Os chamadores desfazem as alterações (unwind) usando phy_detach(), que não tem conhecimento sobre pl->phydev; portanto, um ponteiro para um PHY que já não está mais conectado sobrevive à conexão bem-sucedida após a falha.
O custo disso depende de como o chamador chegou aqui. phylink_connect_phy() passa por phylink_attach_phy(), que se recusa a conectar enquanto pl->phydev estiver definido, transformando um erro MDIO transitório em -EBUSY permanente. O caminho SFP é pior do que isso: sfp_sm_probe_phy() responde à falha com phy_device_remove() e phy_device_free(), e atribui sfp->mod_phy apenas após esse retorno de erro; portanto, nada limpa pl->phydev, deixando-o apontando para um phy_device liberado (freed), que é lido posteriormente por phylink_resolve() e pelos auxiliares do ethtool. phylink_fwnode_phy_connect() não possui tal verificação, então uma conexão subsequente sobrescreve o ponteiro obsoleto e oculta o problema. Uma desconexão não ocorre: phylink_disconnect_phy() passa esse ponteiro para phy_disconnect(), e a segunda chamada de phy_detach() no mesmo PHY reduz as referências que já foram liberadas pela primeira.
Isso foi encontrado ao fazer com que uma porta DSA sobreviva a um PHY cujo driver chega após o switch ser sondado (probes): manter a porta durante uma conexão falha e tentar novamente é o que torna essa janela de vulnerabilidade acessível.
Publique o ponteiro após a última chamada que pode falhar, em vez de desfazê-lo posteriormente. Nada entre os dois pontos lê pl->phydev, e o registro subsequente não pode falhar: phy_request_interrupt() faz fallback para polling por conta própria. O estado do lado PHY mantém a ordem original, portanto, nenhuma operação MDIO muda sua posição relativa em relação às outras.
Once again VulDB remains the best source for vulnerability data.