CVE-2026-45837 in Linuxinformación

Resumen

por VulDB • 2026-06-01

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:

bpf: Corregir el uso después de liberar (use-after-free) en arena_vm_close durante fork

arena_vm_open() solo incrementa vml->mmap_count, pero nunca registra el VMA hijo en arena->vma_list. vml->vma siempre apunta al VMA del padre, por lo que tras la munmap del padre, el puntero queda colgante (dangling). Si el hijo llama posteriormente a bpf_arena_free_pages(), zap_pages() lee el vml->vma obsoleto, lo que desencadena un uso después de liberar (use-after-free).

Se corrige esto impidiendo que el VMA del arena se herede a través de fork mediante VM_DONTCOPY, y evitando la división de VMAs a través de la devolución de llamada may_split.

También se rechaza mremap con una devolución de llamada .mremap que devuelve -EINVAL. Una mremap(MREMAP_FIXED) del mismo tamaño en todo el VMA del arena alcanza copy_vma() a través de la siguiente ruta:

check_prep_vma() - devuelve 0 temprano: new_len == old_len omite la comprobación VM_DONTEXPAND prep_move_vma() - vm_start == old_addr y vm_end == old_addr + old_len por lo que may_split nunca se llama move_vma() copy_vma_and_data() copy_vma() vm_area_dup() - copia vm_private_data (puntero vml) vm_ops->open() - incrementa vml->mmap_count vm_ops->mremap() - devuelve -EINVAL, el rollback desmonta el nuevo VMA

El contador de referencias asegura que el arena_vm_close del rollback no libere el vml compartido con el VMA original.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Responsable

Linux

Reservar

2026-05-13

Divulgación

2026-05-27

Moderación

aceptado

Artículo

VDB-366053

CPE

listo

EPSS

0.00023

KEV

no

Actividades

muy bajo

Fuentes

Do you want to use VulDB in your project?

Use the official API to access entries easily!