Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige un desbordamiento de enteros al procesar la opción de montaje closetimeo. El parámetro de montaje proporcionado por el usuario, closetimeo, de tipo u32, está diseñado para tener un límite superior, pero antes de su validación, el valor se convierte de segundos a jiffies, lo que puede provocar un desbordamiento de enteros. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige el desbordamiento de enteros al procesar la opción de montaje acdirmax. El parámetro de montaje acdirmax, proporcionado por el usuario y de tipo u32, está diseñado para tener un límite superior, pero antes de su validación, el valor se convierte de segundos a jiffies, lo que puede provocar un desbordamiento de enteros. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige un desbordamiento de enteros al procesar la opción de montaje acregmax. El parámetro de montaje acregmax, proporcionado por el usuario y de tipo u32, está diseñado para tener un límite superior, pero antes de su validación, el valor se convierte de segundos a jiffies, lo que puede provocar un desbordamiento de enteros. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el problema de use-after-free en ksmbd_free_work_struct -> la entrada provisional de ksmbd_work podría eliminarse tras la liberación del bloqueo de operón. No es necesario gestionarlo con una lista enlazada. La solicitud provisional podría enviarse inmediatamente cuando se requiera una espera para la interrupción del bloqueo de operón.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: virt: acrn: hsm: Usar kzalloc para evitar fugas de información en pmcmd_ioctl. En la función "pmcmd_ioctl", tres objetos de memoria asignados por kmalloc se inicializan mediante "hcall_get_cpu_state", que posteriormente se copian al espacio de usuario. El inicializador está implementado en "acrn_hypercall2" (arch/x86/include/asm/acrn.h). Existe riesgo de fuga de información debido a bytes no inicializados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: corsair-void: Actualizar los valores de la fuente de alimentación con un controlador de trabajo unificado. corsair_void_process_receiver se puede llamar desde un contexto de interrupción, y bloquear battery_mutex en él causaba un pánico del kernel. Se soluciona moviendo la sección crítica a su propio trabajo, compartiéndolo con battery_add_work y battery_remove_work para eliminar la necesidad de bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netmem: evitar TX de skbs ilegibles Actualmente en árboles estables tenemos soporte para netmem/devmem RX pero no TX. No es seguro reenviar/redirigir un paquete netmem ilegible RX en la ruta TX del dispositivo, ya que el dispositivo puede llamar a las API de mapeo DMA en direcciones DMA que no se le deben pasar. Arregle esto al evitar la xmit de skbs ilegibles. Probado al configurar tc redirect: sudo tc qdisc add dev eth1 ingress sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ip_proto \ tcp src_ip 192.168.1.12 action mirred egress redirect dev eth1 Antes, veía skbs ilegibles en la ruta TX del controlador pasada a las API de mapeo DMA. Después, no veo skbs ilegibles en la ruta TX del controlador pasada a las API de mapeo de DMA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: impide la liberación de la conexión durante la notificación de interrupción del bloqueo de oplock. ksmbd_work podría liberarse después de la liberación de la conexión. Incremente r_count de ksmbd_conn para indicar que las solicitudes aún no han finalizado y para no liberar la conexión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Asignar normalized_pix_clk cuando la profundidad de color es 14 [POR QUÉ Y CÓMO] Se produce un mensaje de advertencia "ADVERTENCIA: CPU: 4 PID: 459 en ... /dc_resource.c:3397 calculate_phy_pix_clks+0xef/0x100 [amdgpu]" porque no se gestiona la profundidad de color de la pantalla = COLOR_DEPTH_141414. Esto se observa en la Radeon RX 6600 XT. Se soluciona asignando pix_clk * (14 * 3) / 24, igual que el resto. También se corrige la sangría en get_norm_pix_clk. (Seleccionado de el commit 274a87eb389f58eddcbc5659ab0b180b37e92775)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: host: pci_generic: Use pci_try_reset_function() para evitar el interbloqueo Hay varios lugares desde donde el trabajo de recuperación se programa de forma asíncrona. Además, hay varios lugares donde el llamador espera de forma síncrona a que se complete la recuperación. Uno de esos lugares es durante la devolución de llamada de PM shutdown(). Si el dispositivo no está activo durante recovery_work, intentará reiniciar el dispositivo utilizando pci_reset_function(). Esta función tomará internamente primero device_lock() antes de reiniciar el dispositivo. En este momento, si el bloqueo ya se ha adquirido, entonces recovery_work se detendrá mientras espera el bloqueo. Y si el bloqueo ya fue adquirido por el llamador que espera a que se complete recovery_work, provocará un interbloqueo. Esto es lo que ocurrió en el dispositivo X1E80100 CRD cuando el dispositivo murió antes de la devolución de llamada de shutdown(). El núcleo del controlador llama a la devolución de llamada de apagado () del controlador mientras mantiene el device_lock(), lo que provoca un interbloqueo. Este bloqueo también puede ocurrir en otras rutas, como durante la devolución de llamada suspend() de PM, donde el núcleo del controlador mantendría el bloqueo_de_dispositivo() antes de llamar a la devolución de llamada suspend() del controlador. Si el trabajo de recuperación ya se había iniciado, podría provocar un bloqueo. Esto también se observa en el CRD X1E80100. Para solucionar ambos problemas, utilice pci_try_reset_function() en el trabajo de recuperación. Esta función primero comprueba la disponibilidad del bloqueo_de_dispositivo() antes de intentar reiniciar el dispositivo. Si el bloqueo está disponible, lo adquirirá y reiniciará el dispositivo. De lo contrario, devolverá -EAGAIN. En este caso, el trabajo de recuperación fallará con el mensaje de error "Error de recuperación", ya que no se pudo hacer mucho.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Establecer la dirección base mmap de hugetlb alineada con el tamaño de pmd Con el caso de prueba ltp "testcases/bin/hugefork02", hay un mensaje de informe de error dmesg como: ¡ERROR del kernel en mm/hugetlb.c:5550! Ups - BUG[#1]: CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 No contaminado 6.14.0-rc2+ #241 Nombre del hardware: QEMU Máquina virtual QEMU, BIOS desconocido 2/2/2022 pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940 a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000 a4 000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000 t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000 t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 000000000000001 t8 000000000000005 u0 9000000004849d0 s9 900000010edbfa00 s0 9000000108d20280 s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10 s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08 ra: 9000000000485538 unmap_vmas+0x130/0x218 ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0 PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EssubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Proceso hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64) Seguimiento de llamadas: [<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0 [<9000000000485534>] unmap_vmas+0x12c/0x218 [<9000000000494068>] exit_mmap+0xe0/0x308 [<900000000025fdc4>] mmput+0x74/0x180 [<900000000026a284>] do_exit+0x294/0x898 [<900000000026aa30>] do_group_exit+0x30/0x98 [<900000000027bed4>] get_signal+0x83c/0x868 [<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0 [<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138 [<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4 El problema radica en que la dirección base asignada desde hugetlbfs no está alineada con el tamaño de pmd. Añada una comprobación para hugetlbfs y alinee la dirección base con el tamaño de pmd. Después de esta corrección, el caso de prueba "testcases/bin/hugefork02" pasa a ejecución. Esto es similar a el commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: enseñar a generic_get_unmapped_area{_topdown} a manejar asignaciones hugetlb").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla1280: Se corrige el error del kernel cuando el nivel de depuración > 2. Eventualmente, se producirá una desreferencia nula o una excepción de error cuando el controlador qla1280.c se compila con DEBUG_QLA1280 habilitado y ql_debug_level > 2. Creo que del código se desprende claramente que la intención aquí es sg_dma_len(s), no la longitud de sg_next(s) al imprimir la información de depuración.