CVE-2026-98801 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
net: restringir SO_RESERVE_MEM a sockets TCP y limitar su valor máximo
Los commits 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") y d00c8ee31729 ("net: fix possible NULL deref in sock_reserve_memory") solo verificaban sk_has_account(sk), lo cual es cierto tanto para sockets TCP como UDP.
Sin embargo, SO_RESERVE_MEM y sk_unused_reserved_mem() actualmente solo son compatibles con TCP: - En los sockets UDP, sk->sk_forward_alloc está protegido por sk->sk_receive_queue.lock, mientras que sock_reserve_memory() y sock_release_reserved_memory() solo adquieren lock_sock(sk). La recepción/liberación concurrente de paquetes UDP y setsockopt(SO_RESERVE_MEM) corrompen sk_forward_alloc y la contabilidad memcg. - udp_rmem_release() recupera el exceso de sk_forward_alloc sin tener en cuenta sk_unused_reserved_mem(sk).
Restringir sock_reserve_memory() a sockets TCP (sk_is_tcp(sk)) por ahora. Soportar SO_RESERVE_MEM para UDP (adquiriendo sk_receive_queue.lock y respetando sk_unused_reserved_mem() en udp_rmem_release()) puede realizarse en una futura serie net-next si fuera necesario.
Además, rechazar val > SZ_1G con -EINVAL en sk_setsockopt(SO_RESERVE_MEM). Sin un límite superior, los valores cercanos a INT_MAX provocan que sk_mem_pages(delta) y (pages << PAGE_SHIFT) desborden el entero de 32 bits con signo, corrompiendo sk->sk_forward_alloc y sk->sk_reserved_mem. El uso de un tope alineado por páginas (SZ_1G) asegura que el valor redondeado a página de sk->sk_reserved_mem informado por getsockopt(SO_RESERVE_MEM) pueda pasarse siempre de nuevo a setsockopt(SO_RESERVE_MEM).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.