Vulnerabilidad en kernel de Linux (CVE-2024-56786)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: poner el programa de bpf_link cuando es seguro desasignarlo En general, se debe considerar que el programa BPF subyacente del enlace BPF es accesible a través de la cadena de gancho de conexión -> enlace -> programa y, de manera pesimista, tenemos que asumir que mientras no sea seguro liberar la memoria del enlace, el código del gancho de conexión podría contener un puntero al programa BPF y usarlo. Como tal, no es (generalmente) correcto poner el programa del enlace antes de esperar a que pasen los GP de RCU. El bpf_prog_put() más ansioso que hacemos actualmente es mayormente correcto debido a que el código de lanzamiento del programa BPF hace una espera similar de GP RCU, pero como se mostrará en los parches siguientes, el programa BPF puede no ser inactivo (y, por lo tanto, depender solo del GP RCU "clásico"), mientras que el gancho de conexión del enlace BPF puede tener semántica inactiva y necesita estar protegido por el Seguimiento de tareas RCU, y para tales casos el enlace BPF tiene que pasar por el Seguimiento de tareas RCU + GP RCU "clásicos" antes de ser desasignado. Y entonces, si ponemos el programa BPF temprano, podríamos liberar el programa BPF antes de liberar el enlace BPF, lo que lleva a una situación de use-after-free. Entonces, este parche pospone bpf_prog_put() hasta que estemos listos para realizar la desasignación de bpf_link. En el peor de los casos, esto retrasa la liberación del programa BPF por un GP RCU adicional, pero eso parece completamente aceptable. Alternativamente, necesitaríamos formas más elaboradas de determinar el gancho BPF, el enlace BPF y la duración del programa BPF, y cómo se relacionan entre sí, lo que parece una complicación innecesaria. Tenga en cuenta que, para la mayoría de los enlaces BPF, seguiremos ejecutando bpf_prog_put() y link dealloc con avidez, por lo que para esos enlaces BPF no hay cambios observables en absoluto. Solo los enlaces BPF que usan dealloc diferido pueden notar una liberación ligeramente retrasada de los programas BPF. Además, para reducir la duplicación de código y lógica, extraiga la lógica de put del programa + link dealloc en el asistente bpf_link_dealloc().