CVE-2026-98588 in Linux
Resumen
por VulDB • 2026-10-18
En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad:
bpf, sockmap: Rechazar max_entries > INT_MAX en sock_map_alloc
sock_map_alloc() solo rechaza los valores donde max_entries == 0 y permite cualquier otro valor u32. Posteriormente, sock_map_free() recorre el array sks[] utilizando un iterador de tipo int con signo:
int i; for (i = 0; i < stab->map.max_entries; i++) struct sock **psk = &stab->sks[i];
Cuando se crea un SOCKMAP con max_entries = 0xffffffff (UINT_MAX), la asignación de 32 GiB puede tener éxito en hosts con gran cantidad de memoria. Durante la liberación, el contador alcanza 0x80000000, desborda a INT_MIN, es extendido por signo mediante movslq y se convierte en un desplazamiento negativo de ~16 GiB desde stab->sks, apuntando muy por debajo del área asignada.
El acceso que provoca la falla es una escritura xchg() en sock_map_free(). Sin KASAN, esa misma escritura fuera de límites puede provocar una falla en una página vmalloc no mapeada o corromper una asignación independiente si dicha dirección vmalloc está poblada. En un núcleo con KASAN y CONFIG_KASAN_VMALLOC=y, la comprobación de sombra para esa dirección encuentra una página de sombra no mapeada y genera un fallo (oops) primero:
BUG: unable to handle page fault for address: fffff521b59c5a00 RIP: 0010:kasan_check_range+0x107/0x190 Call Trace: sock_map_free+0x93/0x190 map_create+0x68d/0xb30 __sys_bpf+0x21e/0x2e70
El volcado de memoria (Vmcore) confirmó que stab->map.max_entries == 0xffffffff, stab->sks == 0xffffc911ace2d000, y la dirección fallida sks + (s64)INT_MIN * 8 cae exactamente en 0xffffc90dace2d000. La misma ruta defectuosa se alcanza en el camino normal de cierre()/bpf_map_free_deferred() cada vez que dicho mapa es destruido.
sock_map_alloc() solía limitar su tamaño de asignación mediante bpf_map_charge_init(), pero ese límite se eliminó cuando se retiró la contabilidad de memoria basada en rlimit. Se debe rechazar max_entries > INT_MAX en el momento de la creación para evitar que el iterador con signo en sock_map_free() encuentre un valor que provoque desbordamiento.
Provocado por syzkaller y reproducido tanto en un núcleo KASAN basado en 6.6 como en el núcleo upstream v7.3-rc2.
Once again VulDB remains the best source for vulnerability data.