Vulnerabilidades

Un problema en EnvisionWare Computer Access & Reservation Control SelfCheck v1.0 (solucionado en OneStop 3.2.0.27184 Hotfix de mayo de 2024) permite a atacantes no autenticados en la misma red realizar un directory traversal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-cgroup: corrupción de la lista de arreglos debido al reordenamiento de WRITE ->lqueued __blkcg_rstat_flush() se puede ejecutar en cualquier momento, especialmente cuando se está ejecutando blk_cgroup_bio_start. Si la ESCRITURA de `->lqueued` se reordena con la READ de 'bisc->lnode.next' en el bucle de __blkcg_rstat_flush(), se puede asignar `next_bisc` agregando una instancia de estadística en blk_cgroup_bio_start(), entonces el La lista local en __blkcg_rstat_flush() podría estar dañada. Solucione el problema agregando una barrera.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-cgroup: corrige la corrupción de la lista al restablecer io stat Desde el commit 3b8cc6298724 ("blk-cgroup: Optimizar blkcg_rstat_flush()"), cada instancia de iostat se agrega a la lista de percpu de blkcg, por lo que blkcg_reset_stats() no puede restablecer la instancia de estadísticas mediante memset(); de lo contrario, la lista puede estar dañada. Solucione el problema reiniciando solo la contraparte.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm: zynqmp_dpsub: Registrar siempre puente Siempre debemos registrar el puente DRM, ya que zynqmp_dp_hpd_work_func llama a drm_bridge_hpd_notify, que a su vez espera que hpd_mutex se inicialice. Hacemos esto antes de zynqmp_dpsub_drm_init ya que llama a drm_bridge_attach. Esto corrige la siguiente advertencia de bloqueo: [19.217084] ------------[ cortar aquí ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock ) [ 19.227768] ADVERTENCIA: CPU: 0 PID: 140 en kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Módulos vinculados en: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 No contaminado 6.6.20+ #96 [19.252046] Nombre de hardware: xlnx,zynqmp (DT) [19.256421] Cola de trabajo: eventos zynqmp_dp_hpd_work_func [19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS PE=-- ) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 8: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 00000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] 4: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9: 0001ff88003f3888 [19.334003] x8: 0001ff88003f3888 x7: 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Seguimiento de llamadas: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ zynqmp_dp_hpd_work_func +0x44/0x54 [ 19.376364] proceso_un_trabajo+0x3ac/0x988 [ 19.380660] hilo_trabajador+0x398/ 0x694 [19.384736] kthread+0x1bc/0x1c0 [19.388241] ret_from_fork+0x10/0x20 [19.392031] sello de evento irq: 183 [19.395450] hardirqs habilitado por última vez en (183): [] terminar_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs deshabilitado por última vez en (182): [] __schedule+0x714/0xd04 [ 19.413612] softirqs habilitado por última vez en (114): [] srcu_invoke_callbacks+0x158/0x23c 19.423128] softirqs se deshabilitó por última vez en ( 110): [] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]--- (seleccionado de el commit 61ba791c4a7a09a370c45b70a81b8c7d4 cf6b2ae)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: evita la corrupción de pt_regs para subprocesos inactivos secundarios La parte superior de la pila de subprocesos del kernel debe reservarse para pt_regs. Sin embargo, este no es el caso de los subprocesos inactivos de los corazones de arranque secundarios. Sus pilas se superponen con sus pt_regs, por lo que ambos pueden corromperse. Se ha solucionado un problema similar para el corazón principal; consulte c7cdd96eca28 ("riscv: evite la corrupción de la pila reservando task_pt_regs(p) anticipadamente"). Sin embargo, esa solución no se propagó a los corazones secundarios. El problema se ha observado en algunas pruebas de conexión en caliente de CPU con V habilitado. La función smp_callin almacenó varios registros en la pila, corrompiendo la parte superior de la estructura pt_regs, incluido el campo de estado. Como resultado, el kernel intentó guardar o restaurar el contexto V inexistente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrigió el tamaño del búfer en gfx_v9_4_3_init_ cp_compute_microcode() y rlc_microcode() La función gfx_v9_4_3_init_microcode en gfx_v9_4_3.c generaba un posible truncamiento de la salida al usar la función snprintf. El problema se debía a que el tamaño del búfer 'ucode_prefix' era demasiado pequeño para acomodar la longitud máxima posible de la cadena que se estaba escribiendo en él. La cadena que se está escribiendo es "amdgpu/%s_mec.bin" o "amdgpu/%s_rlc.bin", donde %s se reemplaza por el valor de 'chip_name'. La longitud de esta cadena sin %s es de 16 caracteres. El mensaje de advertencia indicaba que 'chip_name' podía tener hasta 29 caracteres, lo que daba como resultado un total de 45 caracteres, lo que supera el tamaño del búfer de 30 caracteres. Para resolver este problema, el tamaño del búfer 'ucode_prefix' se ha reducido de 30 a 15. Esto garantiza que la longitud máxima posible de la cadena que se escribe en el búfer no excederá su tamaño, evitando así posibles problemas de desbordamiento y truncamiento del búfer. . Corrige lo siguiente con gcc W=1: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c: En función 'gfx_v9_4_3_early_init': drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:52: advertencia: ' La salida de la directiva de %s puede truncarse escribiendo hasta 29 bytes en una región de tamaño 23 [-Wformat-truncation=] 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~ ...... 439 | r = gfx_v9_4_3_init_rlc_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:9: nota: 'snprintf' genera entre 16 y 45 bytes en un destino de tamaño 30 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:52: advertencia: la salida de la directiva '%s' puede truncarse escribiendo hasta 29 bytes en una región de tamaño 23 [-Wformat-truncation=] 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~ ...... 443 | r = gfx_v9_4_3_init_cp_compute_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:9: nota: 'snprintf' genera entre 16 y 45 bytes en un destino de tamaño 30 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fpga: región: agrega el módulo propietario y toma su recuento. La implementación actual de la región fpga supone que el módulo de bajo nivel registra un controlador para el dispositivo principal y utiliza su puntero de propietario para tomar el recuento del módulo. Este enfoque es problemático ya que puede provocar una desreferencia del puntero nulo al intentar obtener la región durante la programación si el dispositivo principal no tiene un controlador. Para solucionar este problema, agregue un puntero de propietario de módulo a la estructura fpga_region y utilícelo para obtener el recuento del módulo. Modifique las funciones para registrar una región para tomar un parámetro de módulo de propietario adicional y cambiarles el nombre para evitar conflictos. Utilice los nombres de funciones antiguos para las macros auxiliares que configuran automáticamente el módulo que registra la región como propietario. Esto garantiza la compatibilidad con los módulos de control de bajo nivel existentes y reduce las posibilidades de registrar una región sin configurar el propietario. Además, actualice la documentación para que sea coherente con la nueva interfaz para registrar una región fpga.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: solo use instancias BCS reservadas para la cola ejecutiva de migración de usm. La cola de programación de contexto GuC tiene 2 enteros de profundidad, por lo tanto, es posible que un trabajo de migración quede atascado detrás de una falla si la cola ejecutiva de migración comparte motores con los trabajos de los usuarios. Esto puede bloquearse ya que se requiere la cola de ejecución de migración para solucionar los errores de la página. Evite el punto muerto utilizando únicamente instancias BCS reservadas para la cola ejecutiva de migración de usm. (cereza escogida del commit 04f4a70a183a688a60fe3882d6e4236ea02cfc67)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fpga: puente: agrega el módulo propietario y toma su recuento. La implementación actual del puente fpga supone que el módulo de bajo nivel registra un controlador para el dispositivo principal y utiliza su puntero de propietario para tomar el recuento del módulo. Este enfoque es problemático ya que puede provocar una desreferencia del puntero nulo al intentar obtener el puente si el dispositivo principal no tiene un controlador. Para solucionar este problema, agregue un puntero de propietario de módulo a la estructura fpga_bridge y utilícelo para tomar el recuento del módulo. Modifique la función para registrar un puente para tomar un parámetro de módulo propietario adicional y cambiarle el nombre para evitar conflictos. Utilice el nombre de función anterior para una macro auxiliar que configura automáticamente el módulo que registra el puente como propietario. Esto garantiza la compatibilidad con los módulos de control de bajo nivel existentes y reduce las posibilidades de registrar un puente sin configurar el propietario. Además, actualice la documentación para que sea coherente con la nueva interfaz para registrar un puente fpga. Otros cambios: mueva de manera oportunista put_device() de __fpga_bridge_get() a fpga_bridge_get() y of_fpga_bridge_get() para mejorar la claridad del código ya que el dispositivo puente se toma en estas funciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fpga: manager: agrega el módulo propietario y toma su recuento. La implementación actual del administrador fpga supone que el módulo de bajo nivel registra un controlador para el dispositivo principal y usa su puntero de propietario para tomar el recuento del módulo. Este enfoque es problemático ya que puede provocar una desreferencia del puntero nulo al intentar obtener el administrador si el dispositivo principal no tiene un controlador. Para solucionar este problema, agregue un puntero de propietario de módulo a la estructura fpga_manager y utilícelo para tomar el recuento del módulo. Modifique las funciones para registrar el administrador para tomar un parámetro de módulo de propietario adicional y cambiarles el nombre para evitar conflictos. Utilice los nombres de funciones antiguos para las macros auxiliares que configuran automáticamente el módulo que registra al administrador como propietario. Esto garantiza la compatibilidad con los módulos de control de bajo nivel existentes y reduce las posibilidades de registrar un administrador sin configurar el propietario. Además, actualice la documentación para que sea coherente con la nueva interfaz para registrar un administrador fpga. Otros cambios: mueva de manera oportunista put_device() de __fpga_mgr_get() a fpga_mgr_get() y of_fpga_mgr_get() para mejorar la claridad del código ya que el dispositivo administrador se toma en estas funciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: Agregar cabrestante a winch_handlers antes de registrar la IRQ del cabrestante Registrar una IRQ del cabrestante es picante, puede ocurrir una interrupción antes de que el cabrestante se agregue a la lista de winch_handlers. Si eso sucede, Register_winch_irq() agrega a esa lista un cabrestante que está programado para ser liberado (o que ya ha sido) liberado, causando pánico más adelante en winch_cleanup(). Evite la ejecución agregando el cabrestante a la lista winch_handlers antes de registrar la IRQ y retrocediendo si um_request_irq() falla.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: ti: j721e-csi2rx: corrige ejecuciones al reiniciar DMA Después de que el marco se envía a DMA, puede suceder que la lista enviada no se actualice lo suficientemente pronto y la devolución de llamada de DMA se activa antes de eso. Esto puede provocar fallos del kernel, así que mueva todo a una única sección de bloqueo/desbloqueo para evitar este tipo de ejecuciones.