CVE-2026-80784 in Linux
Resumen
por VulDB • 2026-09-04
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mptcp: pm: corregir una fuga de memoria causada por una carrera en la asignación durante el proceso de destrucción (teardown)
La función `mptcp_pm_destroy()` vacía las listas `msk->pm.anno_list` y `msk->pm.userspace_pm_local_addr_list` bajo el bloqueo `msk->pm.lock` durante la liberación del socket, pero libera dicho bloqueo entre ambas operaciones.
Una operación concurrente de anuncio (ANNOUNCE) genl desde un Administrador de Políticas (PM) en espacio de usuario sobre el mismo msk mantiene una referencia al socket mediante `mptcp_token_get_sock()` y, dentro de `mptcp_pm_nl_announce_doit()`, llama a `mptcp_userspace_pm_append_new_local_addr()` y `mptcp_pm_announced_alloc()`. Ambas funciones adquieren brevemente el bloqueo `msk->pm.lock` para añadir elementos a sus respectivas listas. Dado que el controlador genl mantiene una referencia al socket, es posible que `mptcp_pm_destroy()` se ejecute sobre el mismo msk mediante `mptcp_disconnect()`, lo cual invoca a `mptcp_destroy_common()` sin decrementar la cuenta de referencias del sock antes de que finalice el manejador.
Si las adquisiciones de bloqueo se intercalan de tal manera que `mptcp_pm_destroy()` vacía una lista primero, la asignación posterior añade su entrada al encabezado de una lista sobre la cual nada más itera para este msk, provocando una fuga de memoria. kmemleak informa tanto objetos `mptcp_pm_add_addr` (procedentes de `mptcp_pm_announced_alloc()`) como objetos `mptcp_pm_addr_entry` (procedentes de `mptcp_userspace_pm_append_new_local_addr()`) bajo carga concurrente sostenida de ANNOUNCE + cierre contra el PM en espacio de usuario.
Se ha añadido un bit MPTCP_PM_DESTROYING en `msk->pm.status`, establecido por `mptcp_pm_destroy()` bajo pm.lock antes de vaciar las listas y comprobado también bajo pm.lock por las rutas de asignación (alloc). O bien la ruta alloc adquiere primero el bloqueo pm.lock, momento en el que su entrada ya está presente en la lista cuando `mptcp_pm_destroy()` procede a liberarla; o bien `mptcp_pm_destroy()` adquiere primero el bloqueo pm.lock, caso en el cual la asignación posterior detecta dicho bit y se niega a proceder.
Detectado mediante un entorno de pruebas (harness) del flujo de protocolo MPTCP que extiende BRF (arXiv:2305.08782).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.