CVE-2024-41009

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige el exceso de reservas en ringbuf. El búfer de anillo BPF se implementa internamente como un búfer circular de tamaño potencia de 2, con dos contadores lógicos y en constante aumento: consumer_pos es el consumidor contador para mostrar en qué posición lógica el consumidor consumió los datos, y productor_pos, que es el contador del productor que indica la cantidad de datos reservados por todos los productores. Cada vez que se reserva un registro, el productor "dueño" del registro avanzará exitosamente el contador de productores. En el espacio de usuario, cada vez que se lee un registro, el consumidor de los datos avanza el contador del consumidor una vez que finaliza el procesamiento. Ambos contadores se almacenan en páginas separadas de modo que, desde el espacio del usuario, el contador del productor sea de solo lectura y el contador del consumidor sea de lectura y escritura. Un aspecto que simplifica y, por lo tanto, acelera la implementación tanto de productores como de consumidores es cómo el área de datos se mapea dos veces de forma contigua y consecutiva en la memoria virtual, lo que permite no tomar medidas especiales para las muestras que tienen que envolverse en el mismo lugar. al final del área de datos del búfer circular, porque la página siguiente después de la última página de datos volvería a ser la primera página de datos y, por lo tanto, la muestra seguirá apareciendo completamente contigua en la memoria virtual. Cada registro tiene una estructura bpf_ringbuf_hdr { u32 len; u32 página_apagada; } encabezado para la contabilidad de la longitud y el desplazamiento, y es inaccesible para el programa BPF. Ayudantes como bpf_ringbuf_reserve() devuelven `(void *)hdr + BPF_RINGBUF_HDR_SZ` para que lo use el programa BPF. Bing-Jhong y Muhammad informaron que, sin embargo, es posible hacer que un segundo fragmento de memoria asignado se superponga con el primer fragmento y, como resultado, el programa BPF ahora puede editar el encabezado del primer fragmento. Por ejemplo, considere la creación de un mapa BPF_MAP_TYPE_RINGBUF con un tamaño de 0x4000. A continuación, consumer_pos se modifica a 0x3000 /antes/ se realiza una llamada a bpf_ringbuf_reserve(). Esto asignará un fragmento A, que está en [0x0,0x3008], y el programa BPF podrá editar [0x8,0x3008]. Ahora, asignemos un fragmento B con tamaño 0x3000. Esto tendrá éxito porque consumer_pos se editó con anticipación para pasar la verificación `new_prod_pos - cons_pos > rb->mask`. El fragmento B estará en el rango [0x3008,0x6010] y el programa BPF podrá editar [0x3010,0x6010]. Debido al diseño de la memoria del búfer en anillo mencionado anteriormente, los rangos [0x0,0x4000] y [0x4000,0x8000] apuntan a las mismas páginas de datos. Esto significa que el fragmento B en [0x4000,0x4008] es el encabezado del fragmento A. bpf_ringbuf_submit() / bpf_ringbuf_discard() usa el pg_off del encabezado para luego ubicar el bpf_ringbuf a través de bpf_ringbuf_restore_from_rec(). Una vez que el fragmento B modificó el encabezado del fragmento A, bpf_ringbuf_commit() hace referencia a la página incorrecta y podría causar un bloqueo. Solucionelo calculando el pendiente_pos más antiguo y verifique si el rango desde el registro pendiente más antiguo hasta el más nuevo abarcaría más allá del tamaño del búfer circular. Si ese es el caso, rechace la solicitud. Hemos probado con el punto de referencia del búfer de anillo en las autopruebas de BPF (./benchs/run_bench_ringbufs.sh) antes/después de la corrección y, aunque parece un poco más lento en algunos puntos de referencia, todavía no es lo suficientemente significativo como para importar.