Ido Schimmel

Existe um problema no driver team onde um evento `NETDEV CHANGEMTU` é disparado durante o desregistro de um slave. Isso pode levar a uma situação em que o sistema aguarda que um dispositivo de rede seja liberado devido a uma contagem de uso incorreta, podendo causar o travamento do sistema. O problema é desencadeado durante a execução de funções como `team port del()`, `team del slave()` e `team device event()`, que eventualmente chamam `dev set mtu()` e disparam a notificação de alteração de MTU enquanto o dispositivo está sendo desregistrado.

Uma vulnerabilidade no kernel Linux foi resolvida, relacionada à limpeza de entradas FDB, MDB e VLAN durante a desvinculação. O problema surge da suposição de que as camadas superiores mantêm adições e exclusões equilibradas, o que nem sempre é o caso. Isso pode levar a avisos e potenciais vazamentos quando o driver é desvinculado com entradas ainda presentes. A vulnerabilidade está relacionada ao DSA (Arquitetura de Switch Distribuído) e à sua interação com operações de bypass de bridge.

Existe um problema de data-race no kernel Linux relacionado à variável sysctl fib multipath hash fields. A variável pode ser alterada concorrentemente enquanto está sendo lida, o que requer o uso de READ ONCE() para garantir a consistência dos dados.

O problema está relacionado a uma desreferência de ponteiro NULL na rota de erros ao chamar `mlxsw sp acl tcam region destroy()` após uma falha na vinculação de uma região a um grupo ACL. O problema ocorre ao tentar acessar `region->group->tcam`, que é NULL. A correção envolve recuperar o ponteiro `tcam` usando `mlxsw sp acl to tcam()`. Esse problema pode levar a uma negação de serviço.

Uma falha crítica afeta as funções `devlink param set`/`devlink param get` do arquivo `net/core/devlink.c` no componente IPsec, levando a uma situação de uso após liberação de memória. Isso poderia permitir que um invasor executasse código arbitrário.

Ocorre um erro de divisão por zero quando o caminho de dados encontra um grupo de próximo salto resiliente com zero compartimentos. Os testes de resistência do grupo de nexthop resiliente em fib nexthop.sh expuseram essa falha. Os testes substituem um grupo de nexthop resiliente em um loop enquanto o tráfego é encaminhado por ele, fazendo com que o kernel aloque uma tabela stub resiliente com zero buckets. Essa tabela nunca deveria ser visível para o caminho de dados, mas o grupo de nexthop antigo ainda pode ser usado pelo caminho de dados quando a tabela stub é atribuída a ele. A correção envolve apenas atribuir a tabela stub ao antigo grupo nexthop após garantir que o grupo não seja mais usado pelo caminho de dados.