CVE-2026-74576 in Linux
Sumário
de VulDB • 15/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/slab: prevenir recursão ilimitada no caminho de liberação com o novo tipo kmalloc
O commit 280ea9c3154b ("mm/slab: evitar alocação da matriz slabobj_ext do próprio slab") evitou a alocação recursiva de obj_exts dos caches kmalloc do mesmo tamanho, aumentando o tamanho de alocação da matriz obj_exts sempre que o tamanho da matriz fosse igual ao tamanho do objeto sendo alocado.
No entanto, conforme relatado por Danielle Costantino e Shakeel Butt, até slabs provenientes de caches kmalloc de tamanhos diferentes podem formar um ciclo ao alocar matrizes obj_exts uns dos outros [1]:
O que aconteceu: uma matriz obj_exts de um slab KMALLOC_NORMAL (usada pelo perfilamento de alocação / contabilidade memcg) é ela própria alocada via kmalloc() a partir de um cache KMALLOC_NORMAL, portanto, a relação "o slab contém a matriz obj_exts de outro slab" pode formar ciclos. Com sizeof(struct slabobj_ext) == 16 e a geometria do host:
- kmalloc-512 tem 64 objetos/slab -> a matriz é 64*16 == 1024 bytes, servida por kmalloc-1k; - kmalloc-1k tem 32 objetos/slab -> a matriz é 32*16 == 512 bytes, servida por kmalloc-512.
Portanto, um slab kmalloc-512 e um slab kmalloc-1k contêm as matrizes obj_exts uns dos outros. Descartar um libera a matriz do outro, o que esvazia e descarta esse slab, liberando assim a matriz do primeiro, e assim por diante: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() recursa ao longo do ciclo até exaurir a pilha.
Com o perfilamento de alocação de memória, isso permite recursão ilimitada no caminho de liberação e levou a um estouro de pilha (stack overflow) em um host de produção na frota da Meta [1]:
BUG: TASK stack guard page was hit Oops: stack guard page RIP: 0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... (~125x __free_slab kfree) ...
do_syscall_64
Propõe-se [1] resolver este problema servindo sempre a alocação da matriz obj_exts de caches kmalloc (ou kmalloc grande) de tamanhos maiores que o tamanho do objeto. No entanto, conforme
Once again VulDB remains the best source for vulnerability data.