CVE-2026-64045 in Linux
Resumen
por VulDB • 2026-07-20
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
ovpn: tcp - usar puntero peer en caché en ovpn_tcp_close()
ovpn_tcp_close() carga ovpn_socket mediante rcu_dereference_sk_user_data() bajo rcu_read_lock(), toma una referencia sobre sock->peer, almacena el puntero peer en una variable local y libera el lock de lectura. A continuación, pasa sock->peer (en lugar del valor cached local) a ovpn_peer_del(), volviendo a dereferenciar ovpn_socket después de que haya terminado la sección de lectura RCU.
A diferencia de ovpn_tcp_sendmsg(), que utiliza el mismo patrón "carga bajo RCU, uso tras liberar lock" pero está protegida por lock_sock() mantenido durante toda la función, ovpn_tcp_close() se ejecuta sin el socket lock: inet_release() invoca sk_prot->close() sin tomar primero lock_sock.
Por lo tanto, ovpn_socket_release() puede completar su secuencia kref_put -> detach -> synchronize_rcu -> kfree(sock) de forma concurrente, en la ventana posterior a que ovpn_tcp_close() libere rcu_read_lock(), pero antes de dereferenciar sock->peer. El synchronize_rcu() en ovpn_socket_release() protege a los lectores que utilizan el puntero dereferenciado dentro de la sección de lectura RCU, no a aquellos que escapan del puntero hacia una variable local y lo usan posteriormente.
Un programa reproductor sigue el patrón del commit 94560267d6c4 ("ovpn: tcp - no deref NULL sk_socket member after tcp_close()"): desencadenar la eliminación de un peer (expiración keepalive o OVPN_CMD_DEL_PEER por netlink) al mismo momento en que userspace cierra el fd TCP. Ese commit corrigió el lado detach de esa misma ventana de race condition; este corrige el lado close en una víctima diferente.
Restringir el bloque inicial para leer sock->peer exactamente una vez y almacenarla en la variable local cached peer, y dirigir todos los usos posteriores (la comprobación hold, la llamada a ovpn_peer_del() y la invocación prot->close()) a través de esa variable local. sock->peer solo se escribe una vez en ovpn_socket_new() bajo lock_sock(), antes de que rcu_assign_sk_user_data() publique el ovpn_socket, y nunca se reasigna posteriormente; pero el patrón anterior multi-read hacía que esta invariante fuera implícita más bien que explícita. La misma estructura multi-read existe también en ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() y ovpn_tcp_write_space(); estos serán limpiados mediante un helper dedicado en una serie net-next posterior.
If you want to get best quality of vulnerability data, you may have to visit VulDB.