Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/bnxt_re: Se corrige un error al configurar páginas PBL de nivel 2 Evita la corrupción de memoria al configurar páginas PBL de nivel 2 para los recursos que no son MR cuando num_pages > 256K. Habrá una única dirección de página PDE (páginas contiguas en el caso de > PAGE_SIZE), pero la lógica actual supone varias páginas, lo que genera un acceso a memoria no válido después de 256K entradas PBL en el PDE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/bnxt_re: se agrega una comprobación de asignación de memoria. __alloc_pbl() puede devolver un error cuando falla la asignación de memoria. El controlador no está comprobando el estado en una de las instancias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: posix-clock: posix-clock: Corregir bloqueo desequilibrado en pc_clock_settime() Si get_clock_desc() tiene éxito, llama a fget() para el fd del clockid y obtiene el bloqueo de lectura clk->rwsem, por lo que la ruta de error debería liberar el bloqueo para equilibrar el bloqueo y fput el fd del clockid para equilibrar el refcount y liberar el recurso relacionado con el fd. Sin embargo, la siguiente confirmación dejó la ruta de error bloqueada, lo que resultó en un bloqueo desequilibrado. Verifique timespec64_valid_strict() antes de get_clock_desc() para corregirlo, porque el "ts" no se cambia después de eso. [pabeni@redhat.com: se corrigió un error tipográfico en el mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: intel: platform: fix error path in device_for_each_child_node() El bucle device_for_each_child_node() requiere llamadas a fwnode_handle_put() en retornos tempranos para decrementar el refcount del nodo secundario y evitar fugas de memoria si se activa esa ruta de error. Hay un retorno temprano dentro de ese bucle en intel_platform_pinctrl_prepare_community(), pero falta fwnode_handle_put(). En lugar de agregar la llamada faltante, la versión con ámbito del bucle se puede usar para simplificar el código y evitar errores en el futuro si se agregan nuevos retornos tempranos, ya que el nodo secundario solo se usa para analizar y nunca se asigna.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, arm64: Se corrige la emisión de direcciones con KASAN basado en etiquetas habilitado Cuando BPF_TRAMP_F_CALL_ORIG está habilitado, la dirección de una estructura bpf_tramp_image en la pila se pasa durante el paso de cálculo de tamaño y se pasa una dirección en el montón durante la generación de código. Esto puede causar un desbordamiento del búfer del montón si la dirección del montón está etiquetada porque emit_a64_mov_i64() emitirá un código más largo que el que emitió durante el paso de cálculo de tamaño. El mismo problema podría ocurrir sin KASAN basado en etiquetas si una de las palabras de 16 bits de la dirección de la pila fuera todo unos durante el paso de cálculo de tamaño. Solucione el problema asumiendo el peor caso (4 instrucciones) al calcular el tamaño de la emisión de la dirección bpf_tramp_image.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: no intente eliminar un nodo rbtree vacío Al copiar un espacio de nombres, no habremos agregado la nueva copia al rbtree del espacio de nombres hasta que la copia haya tenido éxito. Al llamar a free_mnt_ns() se intentará eliminar la copia del rbtree que no es válida. Simplemente libere el esqueleto del espacio de nombres directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: mtk_eth_soc: se corrige la corrupción de memoria durante la inicialización de fq DMA. El bucle responsable de asignar hasta búferes MTK_FQ_DMA_LENGTH solo debe tocar la cantidad de descriptores, de lo contrario, termina corrompiendo la memoria no relacionada. Corrija el recuento de iteraciones del bucle en consecuencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: no establecer SB_RDONLY después de errores del sistema de archivos Cuando el sistema de archivos se monta con errors=remount-ro, estábamos estableciendo el indicador SB_RDONLY para detener todas las modificaciones del sistema de archivos. Sabíamos que esto omite el bloqueo adecuado (sb->s_umount) y no pasa por el procedimiento de remontaje del sistema de archivos adecuado, pero ha sido la forma en que funcionó desde los primeros días de ext2 y fue lo suficientemente bueno para la mitigación de daños en situaciones catastróficas. Recientemente, syzbot encontró una forma (ver enlace) de activar advertencias en el congelamiento del sistema de archivos porque el código se confundió con SB_RDONLY cambiando bajo sus manos. Desde estos días establecemos EXT4_FLAGS_SHUTDOWN en el superbloque, lo cual es suficiente para detener todas las modificaciones del sistema de archivos, no debería ser necesario modificar SB_RDONLY. Así que deje de hacer eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v4: No permitir un VMOVP en un VPE moribundo Kunkun Jiang informó que hay una pequeña ventana de oportunidad para que el espacio de usuario fuerce un cambio de afinidad para un VPE mientras el VPE ya ha sido desasignado, pero la interrupción del timbre correspondiente aún es visible en /proc/irq/. Conecte la ejecución verificando el valor de vmapp_count, que rastrea si el VPE está asignado o no, y devuelve un error en este caso. Esto implica hacer que vmapp_count sea común tanto para GICv4.1 como para su antecesor v4.0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/entry_32: Borrar los búferes de la CPU después de restaurar el registro en el retorno NMI Los búferes de la CPU se borran actualmente después de la llamada a exc_nmi, pero antes de que se restaure el estado del registro. Esto puede ser adecuado para la mitigación de MDS, pero no para RDFS. Porque la mitigación de RDFS requiere que se borren los búferes de la CPU cuando los registros no tienen datos confidenciales. Mueva CLEAR_CPU_BUFFERS después de RESTORE_ALL_NMI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: sondas: corrige uprobes para kernels big-endian El código de uprobes de arm64 está roto para kernels big-endian ya que no convierte la codificación de instrucciones en memoria (que siempre es little-endian) al endianness nativo del kernel antes de analizar y simular instrucciones. Esto puede resultar en algunos problemas distintos: * El kernel puede rechazar erróneamente el sondeo de una instrucción que puede sondearse de forma segura. * El kernel puede permitir erróneamente el paso de una instrucción fuera de línea cuando esa instrucción no puede ser pasada fuera de línea de forma segura. * El kernel puede simular erróneamente la instrucción incorrectamente durante la interpretación de la codificación de bytes intercambiados. El desajuste de endianness no es detectado por el compilador o sparse porque: * Los campos arch_uprobe::{insn,ixol} están codificados como matrices de u8, por lo que el compilador y sparse no tienen idea de que estos contienen un valor de 32 bits little-endian. El código central de uprobes los llena con un memcpy() que de manera similar no maneja el endianness. * Si bien el tipo uprobe_opcode_t es un alias para __le32, tanto arch_uprobe_analyze_insn() como arch_uprobe_skip_sstep() convierten de u8[] al tipo de nombre similar probe_opcode_t, que es un alias para u32. Por lo tanto, no hay una advertencia de conversión de endianness. Solucione esto cambiando los campos arch_uprobe::{insn,ixol} a __le32 y agregando las conversiones __le32_to_cpu() apropiadas antes de consumir la codificación de instrucciones. El núcleo uprobes copia estos campos como rangos opacos de bytes y, por lo tanto, no se ve afectado por este cambio. Al mismo tiempo, elimine MAX_UINSN_BYTES y use consistentemente AARCH64_INSN_SIZE para mayor claridad. Probado con lo siguiente: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volátil( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | } .... donde la función adrp_self() se compiló a: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Antes de este parche, no se reconocía el ADRP y se asumía que se podía ejecutar paso a paso, lo que provocaba la corrupción del resultado: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | IGUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NO IGUAL Después de este parche, el ADRP se reconoce y simula correctamente: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | IGUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | IGUAL

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: posix-clock: Arreglar la comprobación timespec64 faltante en pc_clock_settime() Como señaló Andrew, tendrá sentido que el núcleo PTP comprobara el rango tv_sec y tv_nsec de la estructura timespec64 antes de llamar a ptp->info->settime64(). Como decía el manual de manual de clock_settime(), si tp.tv_sec es negativo o tp.tv_nsec está fuera del rango [0..999,999,999], debería devolver EINVAL, que incluye relojes dinámicos que manejan el reloj PTP, y la condición es consistente con timespec64_valid(). Como sugirió Thomas, timespec64_valid() solo comprueba que el timespec sea válido, pero no garantiza que el tiempo esté en un rango válido, así que compruébelo con antelación usando timespec64_valid_strict() en pc_clock_settime() y devuelva -EINVAL si no es válido. Hay algunos controladores que usan tp->tv_sec y tp->tv_nsec directamente para escribir registros sin comprobaciones de validez y asumen que la capa superior lo ha comprobado, lo cual es peligroso y se beneficiará de esto, como hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), y algunos controladores pueden eliminar las comprobaciones de sí mismos.