No kernel Linux, a seguinte vulnerabilidade foi resolvida. líquido: nexthop: Aumentar o peso para u 16 Nas redes CLOS, como falhas de ligação ocorrem em vários pontos da rede, os pesos do ECMP dos nós envolvidos são ajustados para compensar. Com um elevado número de nós envolvidos, e um elevado número de nós, uma relação de peso (não-) do ECMP que gostaríamos de configurar não se encaixa em 8 Pedaços. Em vez de, digamos, 255: 254, podemos querer configurar algo como 1000: 999. Para estas implementações, o 8 - o peso do bit pode não ser suficiente. Para esse fim, neste parche aumentar o peso de salto seguinte do u 8 para u 16.

Aumentar a largura de um tipo integral pode ser complicado, porque enquanto o código ainda compila, os tipos podem não verificar mais, e surgir erros numéricos. Para evitar isso, a conversão foi feita em dois passos. Primeiro o tipo foi alterado do u 8 para uma estrutura de um só membro, que invalidou todos os usos do campo. Isto permitiu passar por eles um por um e auditar para a correção do tipo. Então a estrutura foi substituída por um u baunilha 16 novamente. Isto deve garantir que nenhum lugar foi perdido. O UAPI para configurar membros do grupo nexthop é que um atributo NHA_GROUP carrega uma matriz de entradas do next nexthop_grp: struct nexthop_grp { __u 32 id; /* nexthop id - deve existir */ __u 8 peso; /* peso deste nexthop */ __u 8 resvd 1; __ u 16 resvd 2; };.

O campo resvd 1 é validado e necessário ser zero. Podemos levantar este requisito e carregar bits de alta ordem do peso no campo reservado: struct nexthop_grp { __u 32 id; /* nexthop id - deve existir */ __u 8 peso; /* peso deste nexthop */ __u 8 peso_ alto; __u 16 resvd 2; };.

Mantendo os campos divididos desta forma foi escolhido no caso de um espaço de usuário existente fazer suposições sobre a largura do campo de peso, e para evitar quaisquer problemas de endianidade. O campo de peso está codificado como o valor de peso menos um, porque o peso de 0 Não é válido. Este mesmo truque é impossível para o novo campo de peso_ alto, porque zero deve significar zero real. Com isto no lugar:.

- O espaço de usuário antigo está garantido para carregar peso_alto de 0, portanto configurando 8 - Pesos de bits, conforme apropriado. Quando se joga nexthops com 16 - bit peso, ele só mostraria o menor 8 Pedaços. Mas configurar tais nexthops implica a existência de espaço de usuário ciente da extensão em primeiro lugar. - Novo espaço de usuário falando com um kernel antigo funcionará desde que ele apenas tente configurar 8 - bits de peso, onde os bits de alta ordem são zero. O kernel antigo irá rebotar tentativas de configuração > 8 - Pesos de bits.

Renamar campos reservados como eles são alocados para algum propósito é comumente feito no Linux. Quem toca num campo reservado está fazendo isso por sua própria conta e risco. nexthop_ grp::resvd 1 em particular é atualmente usado por pelo menos estrato, porém eles carregam uma cópia própria dos cabeçalhos UAPI, e a conversão deve ser trivial. Um ajudante é fornecido para decodificar o peso dos dois campos. Forçar uma conversão parece preferível a curvar para trás e introduzir uniões anônimas ou qualquer coisa. Registro de aconselhamento: GHSA-v 44 x- j 754 - 46 xf. Identificadores relacionados: CVE- 2024 - 14040.

Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 26 T 09: 30: 21.000 Z e lista a sua última modificação como 2026 - 07 - 27 T 15: 32: 28.000 Z. Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões. Classificação e evidência: nenhum identificador CWE está listado. O registro contém 2 suporte de referências nestes tipos: AVISO, WEB.