CVE-2022-49872 in Linux
Sumário
de VulDB • 06/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net: gso: corrige panic na frag_list com tipos de alocação de head mistos
Desde o commit 3dcbdb134f32 ("net: gso: Corrige splat do skb_segment ao dividir gso_size em skb com frag_list linear-headed"), é permitido alterar o gso_size de um pacote GRO. No entanto, esse commit assume que "verificar o primeiro membro list_skb é suficiente; ou seja, se algum dos membros list_skb tiver um head não head_frag, então o primeiro também terá".
Descobriu-se que essa suposição não se sustenta. Registámos um BUG_ON a ser acionado no skb_segment quando os skbs na frag_list tinham head_frag diferente com o driver vmxnet3. Isto acontece porque __netdev_alloc_skb e __napi_alloc_skb podem retornar um skb que é suportado por página (page backed) ou alocado via kmalloc, dependendo do tamanho solicitado. Como resultado, o último skb pequeno no pacote GRO pode ser alocado via kmalloc.
Existem três localizações diferentes onde isto pode ser corrigido:
(1) Poderíamos verificar o head_frag no GRO e não permitir o GRO de skbs com head_frag diferente. No entanto, isso levaria a uma regressão de desempenho nos caminhos de encaminhamento normais com gso_size inalterado, onde !head_frag no último pacote não é um problema.
(2) Definir uma flag no bpf_skb_net_grow e bpf_skb_net_shrink indicando que o NETIF_F_SG é indesejável. Isso exigiria consumir um bit no sk_buff. Além disso, essa flag pode ser desativada quando todos os skbs na frag_list são suportados por página. Para manter um bom desempenho, o bpf_skb_net_grow/shrink teria de percorrer a frag_list.
(3) Percorrer a frag_list no skb_segment ao determinar se o NETIF_F_SG deve ser limpo. Isto, naturalmente, reduz a velocidade.
Este patch implementa a opção (3). Para limitar o impacto no desempenho no skb_segment, a lista é percorrida apenas para skbs com SKB_GSO_DODGY definido que tenham o gso_size alterado. Os caminhos normais, portanto, não serão afetados.
Poderíamos verificar apenas o último skb, mas como precisamos de percorrer toda a lista de qualquer forma, vamos manter-nos do lado seguro.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.