Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-mapping: benchmark: maneja NUMA_NO_NODE correctamente. Se puede llamar a cpumask_of_node() para NUMA_NO_NODE dentro de do_map_benchmark(), lo que genera el siguiente informe de sanitización: UBSAN: array-index-out-of- Los límites en ./arch/x86/include/asm/topology.h:72:28 el índice -1 están fuera del rango para el tipo 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma No contaminado 6.9. 0-rc6 #29 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan. c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [en línea] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) full_proxy_unlocked_ioctl (fs /debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Utilice cpumask_of_node( ) en su lugar al vincular un subproceso del kernel a un cpuset de un nodo en particular. Tenga en cuenta que la identificación del nodo proporcionada se verifica dentro de map_benchmark_ioctl(). Es sólo un caso NUMA_NO_NODE que no se maneja adecuadamente más adelante. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

La vulnerabilidad de neutralización inadecuada de la entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en WPDeveloper Typing Text permite XSS Almacenado. Este problema afecta a Typing Text: desde n/a hasta 1.2.5.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf/sw-sync: no habilitar IRQ desde sync_print_obj() Desde el commit a6aa8fca4d79 ("dma-buf/sw-sync: reducir irqsave/irqrestore desde el contexto conocido" ) por error reemplazó spin_unlock_irqrestore() con spin_unlock_irq() tanto para sync_debugfs_show() como para sync_print_obj() a pesar de que sync_print_obj() se llama desde sync_debugfs_show(), lockdep se queja de una advertencia de estado de bloqueo inconsistente. Utilice spin_{lock,unlock}() simple para sync_print_obj(), ya que sync_debugfs_show() ya está usando spin_{lock,unlock}_irq().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-mapping: benchmark: corregir la validación de ID de nodo Al validar los ID de nodo en map_benchmark_ioctl(), node_possible() puede recibir un argumento no válido fuera del rango [0,MAX_NUMNODES-1]. lo que lleva a: ERROR: KASAN: acceso a memoria salvaje en map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Lectura de tamaño 8 en la dirección 1fffffff8ccb6398 por tarea dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma No contaminado 6.9. 0-rc6 #37 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/ kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [en línea] arch_test_bit (arch/x86/include/asm/bitops.h:239) [en línea] _test_bit en (incluir /asm-generic/bitops/instrumented-non-atomic.h:142) [en línea] node_state (include/linux/nodemask.h:423) [en línea] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs /debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Comparar ID de nodo con límites cuerdos primero. NUMA_NO_NODE se considera un caso válido especial, lo que significa que los kthreads de evaluación comparativa no estarán vinculados a un cpuset de un nodo determinado. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

La vulnerabilidad de neutralización inadecuada de la entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en John West Slideshow SE permite XSS Almacenado. Este problema afecta a Slideshow SE: desde n/a hasta 2.5.17.

La vulnerabilidad de neutralización inadecuada de la entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en D'arteweb DImage 360 permite XSS Almacenado. Este problema afecta a DImage 360: desde n/a hasta 2.0.

Vulnerabilidad de neutralización inadecuada de la entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en Live Composer Team Page Builder: Live Composer permite XSS Almacenado. Este problema afecta a Page Builder: Live Composer: desde n/a hasta 1.5.42.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: corrigió la condición de terminación del bucle en gss_free_in_token_pages() La matriz in_token->pages[] no tiene terminación NULL. Esto da como resultado el siguiente símbolo KASAN: KASAN: quizás acceso a memoria salvaje en el rango [0x04a2013400000008-0x04a201340000000f]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soundwire: cadencia: corrige el desplazamiento de PDI no válido. Por alguna razón, agregamos un desplazamiento al PDI, presumiblemente para omitir el PDI0 y el PDI1 que están reservados para BPT. Sin embargo, este código es completamente erróneo y conduce a un acceso fuera de los límites. Hasta ahora tuvimos suerte ya que solo usamos un par de PDI y nos mantuvimos dentro de los límites de la matriz de PDI. No se proporciona una etiqueta de Correcciones: ya que no hay plataformas conocidas donde se pueda acceder a los límites, y el código inicial también tenía problemas. Un parche de seguimiento elimina por completo esta compensación inútil.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: multidev: corrección para reconocer una dirección de bloque cero válida. Según lo informado por Yi Zhang en la lista de correo [1], se detectó una advertencia del kernel durante la prueba zbd/010 como se muestra a continuación: ./check zbd/010 zbd/010 (probar soporte de zona de brecha con F2FS) [falló] tiempo de ejecución... 3.752s algo encontrado en dmesg: [4378.146781] ejecutar blktests zbd/010 en 2024-02-18 11:31:13 [4378.192349] null_blk: módulo cargado [4378.209860] null_blk: disco nullb0 creado [4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: recortar poll_queues a 0. poll_q/nr_hw = (0/1) [4378.422334] scsi host15: scsi_debug: versión 019 1 [20210520] dev_size_mb= 1024, opciones = 0x0, enviar_colas = 1, estadísticas = 0 [4378.434922] scsi 15:0:0:0: Acceso directo-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [4378.443343] scsi 15:0:0:0 : Se produjo el encendido o el restablecimiento del dispositivo [ 4378.449371] sd 15:0:0:0: SCSI genérico sg5 tipo 20 adjunto [ 4378.449418] sd 15:0:0:0: [sdf] Dispositivo de bloqueo de zonas administrado por host... (Consulte '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg' ADVERTENCIA: CPU: 22 PID : 44011 en fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio No contaminado 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Seguimiento de llamadas: __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 Entry_SYSCALL_64_after_hwframe +0x6e/0x76 Shinichiro Kawasaki ayuda a analizar este problema y propone un posible parche de solución en [2] . Citado de la respuesta de Shinichiro Kawasaki: "Confirmé que el commit desencadenante es dbf8e63f48af como informó Yi. Eché un vistazo al compromiso, pero me parece bien. Así que pensé que la causa no está en la diferencia de compromiso. Encontré el WARN se imprime cuando f2fs está configurado con múltiples dispositivos y las solicitudes de lectura se asignan al primer bloque del segundo dispositivo en la ruta de lectura directa. En este caso, f2fs_map_blocks() y f2fs_map_blocks_cached() modifican map->m_pblk como. la dirección del bloque físico de cada dispositivo de bloque se vuelve cero cuando se asigna al primer bloque del dispositivo. Sin embargo, f2fs_iomap_begin() asume que map->m_pblk es la dirección del bloque físico de todo el f2fs, en todos los dispositivos de bloque. Compara map->m_pblk con NULL_ADDR == 0, luego ingresa a la rama inesperada y establece la longitud iomap-> no válida. La ADVERTENCIA detecta la longitud iomap-> no válida. Esta ADVERTENCIA se imprime incluso para dispositivos de bloque no zonificados. siguiendo los siguientes pasos: - Cree dos dispositivos null_blk con memoria respaldada con un tamaño de 128 MB cada uno: nullb0 y nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mount_dir}" # dd if=/dev/zero of="${mount_dir}/test.dat" bs =1M count=192 # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct ..." Entonces, la causa principal de este problema es: cuando -la función de dispositivos está activada, f2fs_map_blocks() puede devolver cero blkaddr en un dispositivo no principal, que es una dirección de bloque válida verificada; sin embargo, f2fs_iomap_begin() la trata como una dirección de bloque no válida y luego activa la advertencia en el código del marco iomap Finalmente, como se mencionó, decidimos utilizar una forma más simple y directa que verificar la condición (map.m_flags & F2FS_MAP_MAPPED) en lugar de (map.m_pblk! = NULL_ADDR) para solucionar este problema. y Shinichiro Kawasaki sobre este tema [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ [2] https://lore.kernel. org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: max3100: actualización uart_driver_registered al eliminar el controlador La eliminación del último dispositivo MAX3100 desencadena la eliminación del controlador. Sin embargo, el código no actualiza la variable global respectiva y después del ciclo insmod — rmmod — insmod, el kernel falla: max3100 spi-PRP0001:01: max3100_probe: agregando el puerto 0 ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000408... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Actualice el estado actual para que la próxima vez el controlador UART se registre nuevamente. Hugo también notó que la ruta de error en la sonda también se veía afectada por tener la variable configurada y no borrada. En lugar de borrarlo, mueva la asignación después de la llamada exitosa a uart_register_driver().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: max3100: Bloquear puerto->bloquear al llamar a uart_handle_cts_change() uart_handle_cts_change() debe llamarse con el bloqueo de puerto tomado. Dado que lo ejecutamos en un trabajo separado, el bloqueo puede No se tomará en el momento de correr. Asegúrese de que se tome haciéndolo explícitamente. Sin él, tenemos un símbolo: ADVERTENCIA: CPU: 0 PID: 10 en drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+ 0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]