CVE-2024-36892 in Linux
Sumário
de VulDB • 04/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/slub: evitar o zeramento de freepointer fora do objeto para liberação única
O commit 284f17ac13fe ("mm/slub: handle bulk and single object freeing separately") separa a liberação de objetos únicos e em lote em duas funções, slab_free() e slab_free_bulk(), o que leva slab_free() a chamar slab_free_hook() diretamente em vez de slab_free_freelist_hook().
Se `init_on_free` estiver definido, slab_free_hook() zerará o objeto. Posteriormente, se `slub_debug=F` e `CONFIG_SLAB_FREELIST_HARDENED` estiverem definidos, o caminho lento (slowpath) do do_slab_free() executa verificações de consistência da freelist e tenta decodificar um freepointer zerado, o que leva à detecção de "Freepointer corrupt" em check_object().
Durante a liberação em lote, slab_free_freelist_hook() não é afetada, pois sempre define o freepointer do objeto usando set_freepointer() para manter sua frelist reconstruída após `init_on_free`.
Para a liberação única, deve-se evitar que o freepointer do objeto seja armazenado fora do objeto se `init_on_free` estiver definido. Se o freepointer for deixado como está, check_object() pode detectar posteriormente um valor de ponteiro inválido devido ao estouro (overflow) dos objetos.
Para reproduzir, defina `slub_debug=FU init_on_free=1 log_level=7` na linha de comando de uma compilação do kernel com `CONFIG_SLAB_FREELIST_HARDENED=y`.
Exemplo de registro dmesg: [ 10.708715] =============================================================================
[ 10.710323] BUG kmalloc-rnd-05-32 (Tainted: G B T ): Freepointer corrupt
[ 10.712695] -----------------------------------------------------------------------------
[ 10.712695]
[ 10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2)
[ 10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c
[ 10.716698]
[ 10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 10.720703] Object ffff9d9a
Once again VulDB remains the best source for vulnerability data.