CVE-2026-99127 in Linux
Sumário
de VulDB • 28/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
page_pool: manter frag_offset alinhado para solicitações de tamanho ímpar
page_pool_alloc_frag_netmem() arredonda o tamanho do fragmento solicitado com:
size = ALIGN(size, dma_get_cache_alignment());
dma_get_cache_alignment() retorna 1, a menos que a arquitetura defina ARCH_DMA_MINALIGN, o qual arquiteturas coerentes com DMA, como x86, não fazem. Ali, ALIGN() é uma operação nula e pool->frag_offset avança pelo tamanho bruto, não arredondado.
Um único chamador solicitando um tamanho ímpar deixa então frag_offset desalinhado para cada fragmento extraído dessa página posteriormente. O pool é compartilhado, então o dano não se confina ao chamador que o causou.
O system_page_pool por CPU usado pelo XDP genérico atinge isso. skb_pp_cow_data() aloca seus fragmentos com o comprimento bruto do pacote:
size = min_t(u32, len, PAGE_SIZE); truesize = size; page = page_pool_dev_alloc(pool, &page_off, &truesize);
deixando frag_offset ímpar para qualquer coisa extraída dessa página em seguida. Sua própria alocação de cabeçalho já está alinhada -- SKB_HEAD_ALIGN(size) mais o XDP_PACKET_HEADROOM que seus chamadores passam -- então é um usuário posterior do pool compartilhado que paga: page_pool_dev_alloc_va() retorna um buffer desalinhado, napi_build_skb() o instala como skb->head, e skb_shinfo(skb) == skb->head + skb->end está desalinhado com ele.
dataref de skb_shinfo()-> é um atomic_t de 4 bytes no deslocamento 0x20, então o atomic_inc() em __skb_clone() atravessa uma linha de cache. No x86 com detecção de split lock -- fatal para splits locks do kernel por padrão -- isso causa panic na máquina:
Oops: Split lock detected RIP: 0010:skb_clone+0x154/0x1e0 Call Trace: <IRQ> raw_local_deliver+0x1ed/0x2c0 ip_protocol_deliver_rcu+0x54/0x1c0 ip_local_deliver_finish+0x85/0x100 ip_local_deliver+0x67/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130
Reproduzido ao anexar qualquer programa XDP em modo genérico ao loopback e abrir um socket RAW IPPROTO_UDP, o que faz raw_local_deliver() clonar cada pacote UDP entregue localmente; tráfego DNS comum então aciona isso, aproximadamente uma vez a cada 2500 clones. Observado nas versões 6.12.101 e 7.1.8.
Rastrear page_pool_alloc_frag_netmem() durante um desses run mostra o amplification -- duas solicitações de tamanho ímpar, nove deslocamentos desalinhados:
requested size & 7: 0: 17035 5: 1 7: 1 frag_offset & 7: 0: 17028 3: 1 4: 1 5: 1 6: 1 7: 5
e skb_pp_cow_data() retornando cabeçalhos que estavam alinhados na entrada:
head 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4) head 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5)
Arredonde o tamanho do fragmento para cima, pelo menos até a alinhamento que struct skb_shared_info requer, para que os fragmentos estejam sempre adequadamente alinhados para os objetos que os chamadores constroem sobre eles. Arquiteturas que necessitam de um maior alinhamento DMA mantêm-no.
Isso também torna o resto computado em page_pool_alloc_netmem(),
*size = max_size - *offset;
alinhado, já que max_size é uma potência de dois -- o que corrige a desalinhamento correspondente de skb->end.
Verificado com um A/B controlado sob QEMU/KVM: mesma árvore, mesma configuração, mesmo compilador, mesmo rootfs e tráfego idêntico, diferindo apenas por este patch. Um programa XDP_PASS SEC("xdp.frags") em lo mais datagramas UDP maiores que max_head_size aciona o loop de fragmentos de skb_pp_cow_data(), que passa comprimentos brutos do pacote para o pool. Medido no retorno de skb_pp_cow_data():
unpatched patched skb_pp_cow_data calls 40800 40800 misaligned skb->head 1120 0 dataref at line offset >60 80 0
A última linha conta os acessos que realmente falham: skb_shinfo()->dataref está em head+end+0x20 e é um atomic de 4 bytes, então `lock incl` divide uma linha de cache de 64 bytes apenas quando esse endereço cai no deslocamento 61..63. Todas as 80 ocorrências estavam no deslocamento 61; o panic relatado acima foi no deslocamento 62. Eliminar a desalinhagem remove cada um deles.
Mesma classe de bug que commit 3bed3cc4156e ("net: Do not allocate page fragments t
Be aware that VulDB is the high quality source for vulnerability data.