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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Detectar IP == ksym.end como parte del programa BPF. Ahora que bpf_throw kfunc es la primera instrucción de llamada que no tiene semántica de retorno dentro del verificador, esto también activa el código muerto eliminación de formas sin precedentes. Por un lado, cualquier instrucción que siga a una llamada a bpf_throw nunca se marcará como vista. Además, si una cadena de llamadas termina lanzándose, cualquier instrucción posterior a la instrucción de llamada al subprog que finalmente se lance en las personas que llaman tampoco se marcará como vista. La forma tentadora de solucionar este problema sería emitir instrucciones 'int3' adicionales que superen el jited_len de un programa y garantizar que, durante el tiempo de ejecución, cuando se inicia un programa, podamos descubrir sus límites incluso si la instrucción de llamada a bpf_throw (o a subprogs que siempre tirar) se emite como instrucción final en el programa. Un ejemplo de un programa de este tipo sería este: do_something(): ... r0 = 0 salir foo(): r1 = 0 llamar a bpf_throw r0 = 0 salir de la barra (cond): si r1 != 0 ir a pc+2 llamar a hacer_algo exit call foo r0 = 0 // Nunca visto por el verificador exit // main(ctx): r1 = ... call bar r0 = 0 exit Aquí, si terminamos lanzando, el seguimiento de pila sería el siguiente: bpf_throw foo bar main En bar, la instrucción final emitida será la llamada a foo, como tal, la dirección de retorno será la instrucción posterior (que el JIT emite como int3 en x86). Esto terminará quedando fuera del jited_len del programa, por lo tanto, al desenrollarlo, no podremos descubrir que la dirección del remitente pertenece a ningún programa y terminaremos en pánico debido al desenrollado poco confiable de la pila de programas BPF que nunca esperamos. Para remediar este caso, haga que bpf_prog_ksym_find trate IP == ksym.end como parte del programa BPF, de modo que is_bpf_text_address devuelva verdadero cuando ocurra tal caso, y podamos desenredarlo de manera confiable cuando la instrucción final termine siendo una instrucción de llamada.