Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sysctl: corrige el acceso fuera de los límites para registros sysctl vacíos. Al registrar tablas en el subsistema sysctl, se verifica si el encabezado es un directorio permanentemente vacío (usado para montajes). Esta verificación evalúa el primer elemento de ctl_table. Esto da como resultado una evaluación fuera de los límites al registrar directorios vacíos. La función Register_sysctl_mount_point ahora pasa un ctl_table de tamaño 1 en lugar de tamaño 0. Ahora se basa únicamente en el tipo para identificar un registro permanentemente vacío. Asegúrese de que ctl_table tenga al menos un elemento antes de probar el vacío permanente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: s390: configuración fija del registro fpc kvm_arch_vcpu_ioctl_set_fpu() permite configurar el registro de control de punto flotante (fpc) de una CPU invitada. Se prueba la validez del nuevo valor cargándolo temporalmente en el registro fpc. Esto puede conducir a la corrupción del registro fpc del proceso host: si ocurre una interrupción mientras el valor se carga temporalmente en el registro fpc, y dentro del contexto de interrupción se utilizan registros de punto flotante o vectoriales, los registros fp/vx actuales se guardan con save_fpu_regs() suponiendo que pertenecen al espacio del usuario y se cargarán en los registros fp/vx cuando regresen al espacio del usuario. test_fp_ctl() restaura el valor de registro fpc del proceso de host/espacio de usuario original; sin embargo, se descartará al regresar al espacio de usuario. Como resultado, el proceso del host continuará ejecutándose incorrectamente con el valor que se suponía que debía usarse para una CPU invitada. Solucione este problema simplemente quitando la prueba. Hay otra prueba justo antes de ingresar al contexto SIE que manejará valores no válidos. Esto da como resultado un cambio de comportamiento: ahora se aceptarán valores no válidos en lugar de que el ioctl falle con -EINVAL. Esto parece aceptable, dado que lo más probable es que esta interfaz ya no se use y, además, este es el mismo comportamiento implementado con la interfaz asignada en memoria (reemplace los valores no válidos con cero); consulte sync_regs() en kvm-s390.c.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/ptrace: maneja la configuración del registro fpc correctamente Si el contenido del registro de control de punto flotante (fpc) de un proceso rastreado se modifica con la interfaz ptrace, se prueba el nuevo valor validez cargándolo temporalmente en el registro fpc. Esto puede conducir a la corrupción del registro fpc del proceso de seguimiento: si ocurre una interrupción mientras el valor se carga temporalmente en el registro fpc, y dentro del contexto de interrupción se utilizan registros de punto flotante o vectoriales, los registros fp/vx actuales se guardan con save_fpu_regs() suponiendo que pertenecen al espacio del usuario y se cargarán en los registros fp/vx cuando regresen al espacio del usuario. test_fp_ctl() restaura el valor del registro fpc del espacio de usuario original; sin embargo, se descartará al regresar al espacio de usuario. Como resultado, el rastreador continuará ejecutándose incorrectamente con el valor que se suponía que debía usarse para el proceso rastreado. Solucione este problema guardando el contenido del registro fpu con save_fpu_regs() antes de usar test_fp_ctl().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: rkisp1: Solucionar el problema de ejecución de desactivación de IRQ En rkisp1_isp_stop() y rkisp1_csi_disable() el controlador enmascara las interrupciones y aparentemente asume que el controlador de interrupciones no se ejecutará y continúa en el procedimiento de parada. Este no es el caso, ya que el controlador de interrupciones puede estar ejecutándose, lo que llevaría a que el ISP se deshabilite mientras el controlador de interrupciones maneja una trama capturada. Esto plantea dos problemas: 1) el ISP podría apagarse mientras el controlador de interrupciones aún está ejecutándose y accediendo a los registros, lo que provoca el bloqueo de la placa, y 2) el código del controlador de interrupciones y el código que deshabilita la transmisión pueden hacer cosas que entren en conflicto. No me queda claro si 2) causa un problema real, pero 1) se puede ver con un retraso adecuado (o printk en mi caso) en el controlador de interrupciones, lo que provoca el bloqueo de la placa.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: evite tocar el directorio renombrado si el padre no cambia. El VFS no bloqueará el directorio movido si su padre no cambia. Cambie el código de cambio de nombre de ocfs2 para evitar tocar el directorio renombrado si su padre no cambia sin bloquearlo, lo que puede dañar el sistema de archivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: reiserfs: evite tocar el directorio renombrado si el padre no cambia. El VFS no bloqueará el directorio movido si su padre no cambia. Cambie el código de cambio de nombre de reiserfs para evitar tocar el directorio renombrado si su padre no cambia, sin bloquearlo, lo que puede dañar el sistema de archivos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: libbpf: corrige la desreferencia del puntero NULL en bpf_object__collect_prog_relos Se produjo un problema al leer un archivo ELF en libbpf.c durante la fuzzing: el programa recibió la señal SIGSEGV, falla de segmentación. 0x0000000000958e97 en bpf_object.collect_prog_relos () en libbpf.c:4206 4206 en libbpf.c (gdb) bt #0 0x0000000000958e97 en bpf_object.collect_prog_relos () en libbpf.c:4206 #1 0x0 00000000094f9d6 en bpf_object.collect_relos () en libbpf.c :6706 #2 0x000000000092bef3 en bpf_object_open () en libbpf.c:7437 #3 0x000000000092c046 en bpf_object.open_mem () en libbpf.c:7497 #4 0x0000000000924afa en LLVMFuzzerTest OneInput () en fuzz/bpf-object-fuzzer.c:16 # 5 0x000000000060be11 en testblitz_engine::fuzzer::Fuzzer::run_one () #6 0x000000000087ad92 en tracing::span::Span::in_scope () #7 0x00000000006078aa en testblitz_engine::fuzzer::util::walkdir () #8 0x00000000005f3217 en testblitz_engine::entrypoint::main::{{closure}} () #9 0x00000000005f2601 en main () (gdb) scn_data era nulo en este código (tools/lib/bpf/src/libbpf.c): if (rel ->r_offset % BPF_INSN_SZ || rel->r_offset >= scn_data->d_size) { Los scn_data se derivan del código anterior: scn = elf_sec_by_idx(obj, sec_idx); scn_data = elf_sec_data(obj, scn); relo_sec_name = elf_sec_str(obj, shdr->sh_name); nombre_sec = nombre_sec_elf(obj, scn); if (!relo_sec_name || !sec_name)// no verifica si scn_data es NULL return -EINVAL; En ciertos escenarios especiales, como la lectura de un archivo ELF con formato incorrecto, es posible que scn_data sea un puntero nulo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: wfx: corrige la posible desreferencia del puntero NULL en wfx_set_mfp_ap() Dado que 'ieee80211_beacon_get()' puede devolver NULL, 'wfx_set_mfp_ap()' debe verificar el valor de retorno antes de examinar los datos de skb. Así que convierta este último para que devuelva un código de error apropiado y propáguelo para que regrese también desde 'wfx_start_ap()'. Compilación probada únicamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spmi: mediatek: reparar UAF en la eliminación del dispositivo. Los datos del controlador pmif que contienen los relojes se asignan junto con spmi_controller. Al eliminar el dispositivo, primero se liberará spmi_controller y luego se limpiarán los devres, incluidos los relojes. Esto lleva a UAF porque al poner los relojes se accederá a los relojes en los datos del controlador pmif, que ya están liberados junto con spmi_controller. Esto se puede reproducir habilitando DEBUG_TEST_DRIVER_REMOVE y compilando el kernel con KASAN. Solucione el problema de UAF utilizando clk_bulk_get() no administrado y poniendo los relojes antes de liberar spmi_controller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige una posible desreferencia NULL en amdgpu_ras_query_error_status_helper() Devuelve un código de error no válido -EINVAL para una identificación de bloque no válida. Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 error amdgpu_ras_query_error_status_helper(): anteriormente asumimos que la 'información' podría ser nula (consulte la línea 1176)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: agregue un bloqueo mutex en el control vblank irq. Agregue un bloqueo mutex para controlar vblank irq para sincronizar las operaciones de activación/desactivación de vblank que ocurren desde diferentes subprocesos para evitar condiciones de ejecución durante el registro. /anular el registro de la devolución de llamada vblank irq. v4: -Se eliminó vblank_ctl_lock de dpu_encoder_virt, por lo que es solo un parámetro de dpu_encoder_phys. -Cambiar de refcnt atómico a un contador int simple ya que ahora se ha agregado mutex v3: por error no cambió la redacción en la última versión. Ya está hecho. v2: redacción ligeramente modificada del mensaje de confirmación Patchwork: https://patchwork.freedesktop.org/patch/571854/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/ipoib: corrige el bloqueo de la lista mcast Al liberar `priv->lock` mientras se itera `priv->multicast_list` en `ipoib_mcast_join_task()`, se abre una ventana para `ipoib_mcast_dev_flush( )` para eliminar los elementos mientras se encuentra en medio de la iteración. Si se elimina mcast mientras se elimina el bloqueo, el bucle for gira para siempre, lo que resulta en un bloqueo total (como se informó en el kernel RHEL 4.18.0-372.75.1.el8_6): Tarea A (kworker/u72:2 a continuación) | Tarea B (kworker/u72:0 a continuación) -----------------------------------+---- ------------------------------- ipoib_mcast_join_task(trabajo) | ipoib_ib_dev_flush_light(trabajo) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, lista) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->bloquear) | | spin_lock_irqsave(&priv->bloqueo, banderas) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, lista) | list_del(&mcast->lista); | list_add_tail(&mcast->lista, &remove_list) | spin_unlock_irqrestore(&priv->bloquear, banderas) spin_lock_irq(&priv->bloquear) | | ipoib_mcast_remove_list(&remove_list) (Aquí, `mcast` ya no está en | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` y seguimos | remove_list, list) girando en `remove_list` de | >>> wait_for_completion(&mcast ->hecho) el otro hilo que está bloqueado | y la lista sigue siendo válida | en su pila.) Solucione este problema manteniendo el bloqueo mantenido y cambiando a GFP_ATOMIC para evitar eventuales suspensiones. Desafortunadamente, no pudimos reproducir el bloqueo y confirmar esta solución, pero según la revisión del código, creo que esta solución debería abordar dichos bloqueos. crash> bc 31 PID: 747 TAREA: ff1c6a1a007e8000 CPU: 31 COMANDO: "kworker/u72:2" -- [excepción RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 000000 02 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 00000000000000000 trabajo (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff 1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (también conocido como head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 en ffffff ffc0944ac1 [ ib_ipoib] #6 [ff646f199a8c7e98] Process_one_work+0x1a7 en ffffffff9bf10967 crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> lista -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (vacío) falla> ipoib_dev_priv.mcast_task.work. func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 , mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID: 8 TAREA: ff1c69998efec000 CPU: 33 COMANDO: "kworker/u72:0" -- #3 [ff646f1980153d50] wait_for_completion+0x96 en ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 en ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_ mcast_dev_flush+0x1a7 en ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 en ffffffffc09431a4 [ib_ipoib] # 7 [ff ---truncado---