Vulnerabilidad en kernel de Linux (CVE-2023-52986)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Comprueba si hay algún tcp_bpf_prots al clonar un oyente Un socket que escucha vinculado a un sockmap tiene su sk_prot anulado. Apunta a una de las variantes de struct proto en tcp_bpf_prots. La variante depende de la familia del socket y de los programas sockmap que estén adjuntos. Un socket hijo clonado de un oyente TCP hereda inicialmente su sk_prot. Pero antes de que finalice la clonación, restauramos el proto del hijo al original del oyente que no es tcp_bpf_prots. Esto sucede en tcp_create_openreq_child -> tcp_bpf_clone. Hoy, en tcp_bpf_clone detectamos si el proto del hijo debe restaurarse comprobando solo la variante del proto TCP_BPF_BASE. Esto no es correcto. El sk_prot del socket de escucha vinculado a un mapa de socks puede apuntar a cualquier variante de tcp_bpf_prots. Si el sk_prot del socket de escucha no es la variante TCP_BPF_BASE, el socket hijo se abandona involuntariamente si el sk_prot heredado por tcp_bpf_clone lo impide. Esto genera problemas como la recursión infinita al cerrar [1], ya que el estado del hijo no está configurado para su uso con operaciones de tcp_bpf_prot. Ajuste la comprobación en tcp_bpf_clone para detectar todas las variantes de tcp_bpf_prots. Tenga en cuenta que no sería suficiente comprobar el estado del socket al sobrescribir el sk_prot en tcp_bpf_update_proto para usar siempre la variante TCP_BPF_BASE para los sockets de escucha. Desde el commit b8b8315e39ff ("bpf, sockmap: eliminar el controlador unhash para el uso de sockmap BPF"), es posible que un socket pase al estado TCP_LISTEN mientras ya está vinculado a un sockmap, por ejemplo, connect() -> insert into map -> connect(AF_UNSPEC) -> listen(). [1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/