bluedragonsecurity/cve-2026-31429-pocPOC para CVE-2026-31429 (Linux Kernel >= 6.3 < 6.12.82 Slab Cross-Cache Confusion) - vulnerabilidade descoberta por Antonius - w1sdom - bluedragonsec.com
bpf_prog_test_run_skbGravidade: Média (CWE-763: Liberação de Ponteiro ou Referência Inválida)
Publicado: 2026-04-20
Subsistema afetado: net/core/skbuff.c — skb_kfree_head()
Pesquisador: Antonius / w1sdom — Blue Dragon Security
Contato: [email protected]
Thread Lore: https://lore.kernel.org/netdev/CAK8a0jxC5L5N7hq-DT2_NhUyjBxrPocoiDazzsBk4TGgT1r4-A@mail.gmail.com/
Este repositório contém a prova de conceito para CVE-2026-31429 (não é um exploit funcional, apenas um POC), um bug de confusão cross-cache de slab na pilha de rede do kernel Linux. O bug é acionado quando KFENCE está habilitado e um chamador (especificamente bpf_test_init em net/bpf/test_run.c) aloca um buffer de cabeçalho SKB via kzalloc() com um tamanho que coincide com SKB_SMALL_HEAD_CACHE_SIZE. Devido à semântica de relatório de tamanho exato do KFENCE, a função skb_kfree_head() do kernel libera incorretamente o objeto de volta para skb_small_head_cache em vez do cache kmalloc-1k original, corrompendo os metadados do slab.
| Status | Faixa |
|---|---|
| Afetado | Linux >= 6.3 (introduzido por bf9f1baa279f) |
| Não afetado | < 6.3 |
| Corrigido | >= 6.12.82 |
| Corrigido | >= 6.18.23 |
| Corrigido | >= 6.19.13 |
| Corrigido | >= 7.0 (mainline, commit 0f42e3f4fe2a) |
A vulnerabilidade foi introduzida pelo commit bf9f1baa279f ("net: add dedicated kmem_cache for typical/small skb->head"), que adicionou skb_small_head_cache e a lógica de liberação condicional em skb_kfree_head().
skb_small_head_cacheSKB_SMALL_HEAD_CACHE_SIZE é intencionalmente definido como um valor não potência de 2 (ex.: 704 bytes em x86_64) para evitar colisões com os tamanhos genéricos de buckets do kmalloc (sempre potências de 2: 512, 1024, ...). A heurística em skb_kfree_head() explora essa exclusividade para rotear liberações usando apenas skb_end_offset:
// net/core/skbuff.c (VULNERÁVEL — pré-correção)
static void skb_kfree_head(void *head, unsigned int end_offset)
{
if (end_offset == SKB_SMALL_HEAD_HEADROOM)
kmem_cache_free(net_hotdata.skb_small_head_cache, head);
else
kfree(head);
}
end_offset == SKB_SMALL_HEAD_HEADROOM → assumido como vindo de skb_small_head_cache → kmem_cache_free()kfree() genéricoEssa heurística é válida apenas sob semântica normal de slab, onde ksize() retorna o tamanho do bucket (1024 para uma solicitação de 704 bytes), que nunca é igual a SKB_SMALL_HEAD_CACHE_SIZE.
KFENCE (Kernel Electric-Fence) intercepta um subconjunto de alocações do kernel e as atende a partir de memória com páginas de guarda. Sua diferença comportamental crítica: kfence_ksize() retorna o tamanho exato solicitado, não o tamanho do bucket do slab.
BPF_PROG_TEST_RUN (syscall 321, cmd BPF_PROG_TEST_RUN=10)
└─> __sys_bpf()
└─> bpf_prog_test_run_skb()
└─> bpf_test_init()
└─> kzalloc(size, GFP_USER)
│ size == SKB_SMALL_HEAD_CACHE_SIZE (704 em x86_64)
│ KFENCE intercepta → objeto atendido da região kmalloc-1k
│
└─> slab_build_skb(data, NULL, size)
└─> ksize(data)
└─> kfence_ksize() ← retorna 704 (exato!)
└─> skb_end_offset
= ksize(data) - sizeof(skb_shared_info)
= 704 - 320
= 384
= SKB_SMALL_HEAD_HEADROOM ← correspondência falsa!
[No caminho de liberação do SKB:]
└─> sk_skb_reason_drop()
└─> skb_release_data()
└─> skb_free_head()
└─> skb_kfree_head(head, skb->end)
└─> (end_offset == SKB_SMALL_HEAD_HEADROOM) == TRUE
└─> kmem_cache_free(skb_small_head_cache, head)
↑ BUG: head é de kmalloc-1k, não de skb_small_head_cache!
→ warn_free_bad_obj() → corrupção do SLUB
skb_end_offset = 384?Em x86_64:
SKB_SMALL_HEAD_CACHE_SIZE = 704 bytes
sizeof(skb_shared_info) = 320 bytes
SKB_SMALL_HEAD_HEADROOM = 704 - 320 = 384
Quando o KFENCE intercepta o kzalloc() de 704 bytes, kfence_ksize() retorna exatamente 704. A aritmética produz skb_end_offset = 384 = SKB_SMALL_HEAD_HEADROOM, satisfazendo a condicional em skb_kfree_head() — acionando o caminho de liberação errado.
A correção upstream por Jiayuan Chen (revisada por Eric Dumazet, mesclada por Jakub Kicinski) elimina a heurística por completo:
// net/core/skbuff.c (CORRIGIDO)
static void skb_kfree_head(void *head, unsigned int end_offset)
{
kfree(head); // sempre genérico; funciona para ambos os casos
}
kfree() é seguro tanto para memória alocada via kmalloc quanto para memória alocada via skb_small_head_cache porque kmem_cache_free() em skb_small_head_cache não é mais necessário — o kfree() genérico resolve o cache correto internamente por meio do ponteiro kmem_cache da página do slab.
O reprodutor (repro_bpf.c) foi executado no Linux 7.0.0-rc5 em um ambiente QEMU (i440FX, BIOS 1.17.0-debian). A seguinte cascata de WARNINGs do kernel foi observada:
[ 3065.322973] ------------[ cut here ]------------
[ 3065.322990] kmem_cache_free(skbuff_small_head, ffff888186d6e000): object belongs to different cache kmalloc-1k
[ 3065.323005] WARNING: mm/slub.c:6258 at warn_free_bad_obj+0x91/0xc0, CPU#0: repro_bpf/2167
[ 3065.323061] CPU: 0 UID: 0 PID: 2167 Comm: repro_bpf Not tainted 7.0.0-rc5 #1 PREEMPT(lazy)
[ 3065.323098] RIP: 0010:warn_free_bad_obj+0x98/0xc0
...
[ 3065.323231] Call Trace:
[ 3065.323247] skb_free_head+0x1ec/0x290
[ 3065.323267] skb_release_data+0x7a6/0x9d0
[ 3065.323308] bpf_prog_test_run_skb+0x14f8/0x3410
[ 3065.323510] __sys_bpf+0x769/0x4b60
[ 3065.323763] __x64_sys_bpf+0x78/0xc0
[ 3065.323794] do_syscall_64+0x111/0x690
[ 3065.323813] entry_SYSCALL_64_after_hwframe+0x77/0x7f
A cascata de WARNINGs produz 4 splats separados por acionamento:
warn_free_bad_obj — detecção primária de liberação cross-cache (mm/slub.c:6258)depot_fetch_stack — índice do pool do stack depot fora dos limites (lib/stackdepot.c:506) no rastreamento Allocatedstack_depot_print — handle corrompido detectado (lib/stackdepot.c:780)depot_fetch_stack + stack_depot_print — mesmo par repetido para o rastreamento FreedEssa cascata indica que os metadados de rastreamento do SLUB do objeto (alloc_track / free_track) referenciam um handle do stack depot que se torna corrompido após a liberação no cache errado.