CVE-2026-98588 in Linux
Sumário
de VulDB • 19/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
bpf, sockmap: Rejeitar max_entries > INT_MAX em sock_map_alloc
sock_map_alloc() rejeita apenas quando max_entries == 0 e permite qualquer valor u32 caso contrário. Em seguida, sock_map_free() percorre o array sks[] com um iterador do tipo int assinado:
int i; for (i = 0; i < stab->map.max_entries; i++) struct sock **psk = &stab->sks[i];
Quando um SOCKMAP é criado com max_entries = 0xffffffff (UINT_MAX), a alocação de 32 GiB pode ter sucesso em hosts com grande quantidade de memória. Durante a liberação, o contador atinge 0x80000000, transborda para INT_MIN, é estendido por sinal pela instrução movslq e se torna um deslocamento negativo de ~16 GiB em relação a stab->sks, apontando muito abaixo da alocação.
O acesso que causa falha (fault) é uma gravação via xchg() em sock_map_free(). Sem o KASAN, a mesma escrita fora dos limites pode causar falha em uma página vmalloc não mapeada ou corromper uma alocação não relacionada se esse endereço vmalloc estiver populado. Em um kernel com KASAN e CONFIG_KASAN_VMALLOC=y, a verificação de sombra (shadow check) para esse endereço aciona uma página de sombra não mapeada e gera um oops primeiro:
BUG: unable to handle page fault for address: fffff521b59c5a00 RIP: 0010:kasan_check_range+0x107/0x190 Call Trace: sock_map_free+0x93/0x190 map_create+0x68d/0xb30 __sys_bpf+0x21e/0x2e70
O Vmcore confirmou que stab->map.max_entries == 0xffffffff, stab->sks == 0xffffc911ace2d000 e o endereço com falha sks + (s64)INT_MIN * 8 está exatamente em 0xffffc90dace2d000. O mesmo caminho defeituoso é alcançado no caminho normal de close()/bpf_map_free_deferred() sempre que tal mapa é destruído.
sock_map_alloc() anteriormente limitava o tamanho da sua alocação através de bpf_map_charge_init(), mas essa restrição foi removida quando a contabilidade de memória baseada em rlimit foi eliminada. Rejeitar max_entries > INT_MAX no momento da criação para que o iterador assinado em sock_map_free() nunca veja um valor que cause transbordo (overflow).
Acionado pelo syzkaller e reproduzido tanto em um kernel KASAN baseado na versão 6.6 quanto no kernel upstream v7.3-rc2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.