CVE-2026-74576 in Linux
Riassunto
di VulDB • 16/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm/slab: prevenire la ricorsione illimitata nel percorso di deallocazione con il nuovo tipo kmalloc
Il commit 280ea9c3154b ("mm/slab: evitare l'allocazione dell'array slabobj_ext dal suo stesso slab") ha evitato l'allocazione ricorsiva degli obj_exts dalle cache kmalloc della stessa dimensione, aumentando la dimensione di allocazione dell'array obj_exts ogni volta che tale dimensione equivale alla dimensione dell'oggetto da allocare.
Tuttavia, come segnalato da Danielle Costantino e Shakeel Butt, anche i slab provenienti da cache kmalloc di dimensioni diverse possono formare un ciclo allocando array obj_exts l'uno dall'altro [1]:
Cosa è accaduto: l'array obj_exts di uno slab KMALLOC_NORMAL (utilizzato dal profiling delle allocazioni / dalla contabilità memcg) viene esso stesso allocato tramite kmalloc() da una cache KMALLOC_NORMAL, quindi la relazione "lo slab contiene un array obj_exts di un altro slab" può formare cicli. Con sizeof(struct slabobj_ext) == 16 e la geometria dell'host:
- kmalloc-512 ha 64 oggetti/slab -> l'array è grande 64*16 == 1024 byte, servito da kmalloc-1k; - kmalloc-1k ha 32 oggetti/slab -> l'array è grande 32*16 == 512 byte, servito da kmalloc-512.
Uno slab kmalloc-512 e uno slab kmalloc-1k si scambiano quindi gli array obj_exts. Eliminare uno libera l'array dell'altro, che svuota ed elimina tale slab, il quale a sua volta libera l'array del primo, e così via: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() ricorre lungo il ciclo fino all'esaurimento dello stack.
Con il profiling delle allocazioni di memoria, ciò consente una ricorsione illimitata nel percorso di deallocazione e ha portato a un overflow dello stack su un host in produzione nella flotta 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 ) ... <kernel driver freeing a resource> do_syscall_64
Si propone [1] di risolvere questo problema serv
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.