CVE-2026-89579 in Linux
Sumário
de VulDB • 12/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
bpf: Fortalecimento da dimensionamento e indexação do filtro bloom em kernels de 32 bits
O bloco `bloom_map_alloc()` apresenta dois problemas específicos para ambientes de 32 bits quando o bitmap calculado atinge o caso de fallback U32_MAX.
Primeiro, `BITS_TO_BYTES(U32_MAX)` é avaliado com aritmética de 32 bits. A adição realizada por `DIV_ROUND_UP` sofre wrap-around (estouro), fazendo com que o mapa aloque apenas o objeto do filtro bloom de tamanho fixo, mantendo `bitset_mask == U32_MAX`. Atualizações subsequentes podem então gravar além do objeto alocado.
Segundo, corrigir apenas o tamanho da alocação não é suficiente. O hash do bloom é um u32, mas `set_bit()` espera um número de bit como signed long e `test_bit()` no x86 eventualmente alimenta o índice para `variable_test_bit(long, ...)`. Em kernels de 32 bits, os hashes em `[0x80000000, U32_MAX]` tornam-se deslocamentos (offsets) negativos. As instruções bt/bts do x86 com um operando de memória interpretam esses offsets relativos à base fornecida; portanto, um mapa com `bitset_mask == U32_MAX` pode ler ou escrever antes mesmo de `bloom->bitset`, mesmo após a alocação do bitmap completo de 512 MiB.
Mantém-se o fallback para U32_MAX, mas divide-se cada hash em um ponteiro de palavra e um número de bit dentro da palavra antes de chamar `test_bit()` ou `set_bit()`. O argumento das operações de bit (bitops) fica então sempre em `[0, BITS_PER_LONG - 1]`, enquanto `BIT_WORD(h)` ainda seleciona a palavra pretendida no bitmap completo.
Calcula-se o tamanho do bitset como `(u64)bitset_mask + 1` antes de passar o tamanho final para `bpf_map_area_alloc()`. Isso corrige a subalocação original e mantém o armazenamento alocado consistente com o bitset endereçável.
Nota sobre exploração: é possível escalonamento local de privilégios em um kernel x86 de 32 bits usando o bug de subalocação a partir de um binário com CAP_BPF.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.