CVE-2023-52452

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige los accesos a las ranuras de la pila uninit. Se supone que los programas privilegiados pueden leer la memoria de la pila no inicializada (desde 6715df8d5) pero, antes de este parche, estos accesos se permitían de forma inconsistente. En particular, se permitían accesos por encima de state->allocated_stack, pero no por debajo de él. En otras palabras, si la pila ya era "lo suficientemente grande", se permitía el acceso, pero en caso contrario se rechazaba el acceso en lugar de permitir "hacer crecer la pila". Este rechazo no deseado ocurría en dos lugares: - en check_stack_slot_within_bounds() - en check_stack_range_initialized() Este parche dispone que estos accesos sean permitidos. Un montón de pruebas que dependían del antiguo rechazo tuvieron que cambiar; todos ellos se cambiaron para agregar que también se ejecutan sin privilegios, en cuyo caso el comportamiento anterior persiste. Una prueba no se pudo actualizar (global_func16) porque no se puede ejecutar sin privilegios por otros motivos. Este parche también corrige el seguimiento del tamaño de la pila para lecturas con desplazamiento variable. Esta segunda solución se incluye en la misma confirmación que la primera porque están interrelacionadas. Antes de este parche, las escrituras en la pila usando registros que contenían un desplazamiento variable (a diferencia de registros con valores fijos y conocidos) no contribuían adecuadamente al tamaño de pila necesario de la función. Como resultado, era posible que un programa verificara, pero luego intentara leer datos fuera de límites en tiempo de ejecución porque se le había asignado una pila demasiado pequeña. Cada función rastrea el tamaño de la pila que necesita en bpf_subprog_info.stack_ Depth, que es mantenido por update_stack_ Depth(). Para accesos regulares a la memoria, check_mem_access() estaba llamando a update_state_ Depth() pero pasaba solo la parte fija del registro de compensación, ignorando la variable compensación. Esto era incorrecto; en su lugar se debe utilizar el valor mínimo posible de ese registro. Este seguimiento ahora se soluciona centralizando el seguimiento del tamaño de la pila en grow_stack_state() y elevando las llamadas a grow_stack_state() a check_stack_access_within_bounds() como lo sugiere Andrii. El código ahora es más simple y rastrea de manera más convincente el tamaño máximo de pila correcto. check_stack_range_initialized() ahora puede confiar en que se haya asignado suficiente pila para el acceso; esto ayuda con la solución del primer problema. Se cambiaron algunas pruebas para verificar también el cálculo de la profundidad de la pila. El que falla sin este parche es verifier_var_off:stack_write_priv_vs_unpriv.