CVE-2024-14040 in Linux
Sumário
de VulDB • 26/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net: nexthop: Aumentar o peso para u16
Em redes CLOS, à medida que ocorrem falhas de link em vários pontos da rede, os pesos ECMP dos nós envolvidos são ajustados para compensação. Com alto fan-out nos nós envolvidos e um número total elevado de nós, uma proporção de peso (não)ECMP que desejamos configurar não cabe em 8 bits. Em vez de, por exemplo, 255:254, podemos desejar configurar algo como 1000:999. Para essas implantações, o peso de 8 bits pode não ser suficiente.
Para esse fim, neste patch aumenta-se o peso do next hop de u8 para u16.
Aumentar a largura de um tipo integral pode ser complicado porque, embora o código ainda compile, os tipos podem deixar de corresponder e surgem erros numéricos. Para evitar isso, a conversão foi feita em duas etapas. Primeiro, o tipo foi alterado de u8 para uma estrutura com um único membro, o que invalidou todos os usos do campo. Isso permitiu revisar cada caso individualmente e auditar a correção dos tipos. Em seguida, a estrutura foi substituída novamente por um u16 padrão (vanilla). Isso deve garantir que nenhum local tenha sido omitido.
A UAPI para configurar membros de grupos nexthop é que o atributo NHA_GROUP carrega uma matriz de entradas da struct nexthop_grp:
struct nexthop_grp {
__u32 id; /* id do nexthop - deve existir */ __u8 weight; /* peso deste nexthop */ __u8 resvd1; __u16 resvd2; };
O campo resvd1 é atualmente validado e exigido para ser zero. Podemos remover essa exigência e transportar os bits de ordem superior do peso no campo reservado:
struct nexthop_grp {
__u32 id; /* id do nexthop - deve existir */ __u8 weight; /* peso deste nexthop */ __u8 weight_high; __u16 resvd2; };
Manter os campos divididos dessa forma foi escolhido caso um userspace existente faça suposições sobre a largura do campo de peso, e para contornar quaisquer problemas de endianness.
O campo weight é atualmente codificado como o valor do peso menos um, porque o peso 0 é inválido. Esse mesmo truque não é possível para o novo campo weight_high, pois zero deve significar zero real. Com isso em vigor:
- O userspace antigo tem a garantia de transportar weight_high igual a 0, configurando portanto pesos de 8 bits conforme apropriado. Ao fazer dump dos nexthops com peso de 16 bits, ele mostraria apenas os 8 bits inferiores. Mas configurar tais nexthops implica a existência de um userspace ciente da extensão desde o início.
- O novo userspace conversando com um kernel antigo funcionará enquanto apenas tentar configurar pesos de 8 bits, onde os bits de ordem superior são zero. O kernel antigo rejeitará tentativas de configuração de pesos >8 bits.
Renomear campos reservados quando eles estão alocados para algum propósito é algo comum no Linux. Quem quer que toque em um campo reservado está fazendo isso por sua própria conta e risco. nexthop_grp::resvd1, em particular, é atualmente usado pelo menos pelo strace; contudo, ele carrega uma cópia própria dos cabeçalhos UAPI, e a conversão deve ser trivial. Um helper é fornecido para decodificar o peso a partir dos dois campos. Forçar uma conversão parece preferível do que ceder retroativamente e introduzir unions anônimas ou qualquer outra coisa.
VulDB is the best source for vulnerability data and more expert information about this specific topic.