Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: se corrige la advertencia al destruir 'cifs_io_request_pool' Hay un problema como el siguiente: ADVERTENCIA: CPU: 1 PID: 27826 en mm/slub.c:4698 free_large_kmalloc+0xac/0xe0 RIP: 0010:free_large_kmalloc+0xac/0xe0 Rastreo de llamadas: ? Obviamente, 'cifs_io_request_pool' no es creado por mempool_create(). Entonces simplemente use mempool_exit() para revertir 'cifs_io_request_pool'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Deshabilitar PSR-SU también en Parade 08-01 TCON Stuart Hayhurst ha descubierto que tanto en el arranque como en pantalla completa, el vídeo VA-API provoca pantallas negras durante alrededor de 1 segundo y rastros de ADVERTENCIA [1] en el kernel al llamar a dmub_psr_enable() con Parade 08-01 TCON. Todos estos síntomas desaparecen con PSR-SU deshabilitado para este TCON, así que deshabilítelo por ahora mientras se pueden analizar los rastros DMUB [2] del fallo y se puede determinar correctamente el estado del fallo. (seleccionado de la confirmación afb634a6823d8d9db23c5fb04f79c5549349628b)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: corrige una fuga de información del kernel más en el volcado de algoritmos. Durante las pruebas fuzz, se descubrió el siguiente problema: ERROR: KMSAN: fuga de información del kernel en _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Ununit se almacenó en la memoria en: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit se creó en: __kmalloc+0x571/0xd30 attached_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Los bytes 328-379 de 732 no están inicializados El acceso a la memoria de tamaño 732 comienza en ffff88800e18e000 Datos copiados a la dirección de usuario 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 No contaminado 6.8.11 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Corrige la copia de algoritmos xfrm donde algunos datos aleatorios de los campos de estructura pueden terminar en el espacio de usuario. El relleno en las estructuras se puede rellenar con datos aleatorios (posiblemente confidenciales) y nunca se debe proporcionar directamente al espacio de usuario. Un problema similar se resolvió en la confirmación 8222d5910dae ("xfrm: relleno de ceros al volcar algoritmos y encap") encontrado por Linux Verification Center (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: nSVM: Ignorar nCR3[4:0] al cargar PDPTE desde la memoria Ignorar nCR3[4:0] al cargar PDPTE desde la memoria para SVM anidado, ya que los bits 4:0 de CR3 se ignoran cuando se utiliza la paginación PAE y, por lo tanto, VMRUN no aplica la alineación de 32 bytes de nCR3. En el peor de los casos, no ignorar los bits 4:0 puede dar como resultado una lectura fuera de los límites, por ejemplo, si la página de destino está al final de un memslot y el VMM no está utilizando páginas de protección. Según el APM: El registro CR3 apunta a la dirección base de la tabla de punteros de directorio de páginas. La tabla de punteros de directorio de página está alineada en un límite de 32 bytes, y se supone que los 5 bits de dirección bajos 4:0 son 0. Y el SDM es mucho más explícito: 4:0 Ignorado. Tenga en cuenta que KVM hace esto correctamente al cargar PDPTR, es solo el flujo nSVM el que está dañado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: se corrige un error del kernel debido a la falta de limpieza del indicador de retraso del búfer Syzbot informó que después de que nilfs2 lee una imagen de sistema de archivos corrupta y se degrada a solo lectura, la comprobación BUG_ON para el indicador de retraso del búfer en submission_bh_wbc() puede fallar, lo que provoca un error del kernel. Esto se debe a que el indicador de retraso del búfer no se borra al borrar los indicadores de estado del búfer para descartar una página/folio o un encabezado de búfer. Por lo tanto, solucione esto. Esto se volvió necesario cuando se expandió el uso de la propia rutina de limpieza de páginas de nilfs2. Esta inconsistencia de estado no ocurre si el búfer se escribe normalmente mediante la escritura de registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd: Protección contra datos erróneos para el método ACPI de ATIF Si un BIOS proporciona datos erróneos en respuesta a una llamada al método ATIF, esto provoca una desreferencia de puntero NULL en el llamador. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminador 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminador 2) arch/x86/mm/fault.c:705 (discriminador 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminador 1) arch/x86/mm/fault.c:1232 (discriminador 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminador 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminador 1)) amdgpu ``` Se ha detectado en al menos un sistema, por lo que debe tener cuidado. (seleccionado de la confirmación c9b7c809b89f24e9372a4e7f02d64c950b07fdee)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: dummy-hcd: soluciona el problema de "tarea colgada" El fuzzer syzbot ha estado encontrando problemas de "tarea colgada" desde que se cambió el controlador dummy-hcd para usar temporizadores hrtimer en lugar de temporizadores normales. Resulta que los problemas son causados por una diferencia sutil entre las API timer_pending() y hrtimer_active(). El cambio reemplazó ciegamente la primera por la segunda. Sin embargo, timer_pending() devuelve True cuando el temporizador está en cola pero no cuando su devolución de llamada se está ejecutando, mientras que hrtimer_active() devuelve True cuando el hrtimer está en cola _o_ su devolución de llamada se está ejecutando. Esta diferencia ocasionalmente hizo que dummy_urb_enqueue() pensara que la rutina de devolución de llamada aún no había comenzado cuando, de hecho, estaba casi terminada. Como resultado, el hrtimer no se reinició, lo que hizo imposible que el controlador quitara de la cola más tarde el URB que acababa de ponerse en cola. Esto provocó que usb_kill_urb() se bloqueara y las cosas empeoraron a partir de ahí. Dado que los temporizadores hr no tienen una API para saber cuándo están en cola y la devolución de llamada no se está ejecutando, el controlador debe realizar un seguimiento de esto por sí mismo. Eso es lo que hace este parche, agregando un nuevo indicador "timer_pending" y configurándolo o borrándolo en los momentos apropiados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86: se soluciona el problema de especulación no canónica de enmascaramiento de direcciones de usuario Resulta que AMD tiene un problema de "Meltdown Lite(tm)" con los accesos no canónicos en el espacio del kernel. Y entonces, usar solo el bit alto para decidir si un acceso está en el espacio del usuario o en el espacio del kernel termina con la buena y vieja "filtración de datos especulativos" si tienes el gadget correcto usando el resultado: CVE-2020-12965 "Ejecución transitoria de accesos no canónicos" Ahora, el kernel rodea el acceso con un par STAC/CLAC, y esas instrucciones terminan serializando la ejecución en arquitecturas Zen más antiguas, lo que cierra la ventana de especulación. Pero eso era cierto solo hasta Zen 5, que renombra el bit AC [1]. Eso mejora mucho el rendimiento de STAC/CLAC, pero también significa que la ventana de especulación ahora está abierta. Tenga en cuenta que esto no solo afecta al nuevo enmascaramiento de dirección, sino también a la comprobación regular valid_user_address() utilizada por access_ok() y a la versión asm de la comprobación del bit de signo en los ayudantes get_user(). No afecta a las variantes put_user() o clear_user(), ya que no hay ningún resultado especulativo que se pueda utilizar en un gadget para esas operaciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: sdm845: agregar asignación de flujo de tiempo de ejecución de Soundwire faltante Durante la migración de la asignación de flujo de tiempo de ejecución de Soundwire desde el controlador Qualcomm Soundwire a los controladores de tarjeta de sonido del SoC, se olvidó la tarjeta de sonido sdm845. En este punto, cualquier intento de reproducción o inicio del daemon de audio, por ejemplo en sdm845-db845c (placa Qualcomm RB3), dará como resultado una desreferenciación del puntero de flujo NULL: No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000020 Información de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: error de traducción de nivel 0 Información de aborto de datos: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Superposición = 0, DirtyBit = 0, Xs = 0 usuario pgtable: páginas de 4k, VA de 48 bits, pgdp=0000000101ecf000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Error interno: Oops: 0000000096000004 [#1] PREEMPT Módulos SMP vinculados en: ... CPU: 5 UID: 0 PID: 1198 Comm: aplay No contaminado 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18 Nombre del hardware: Thundercomm Dragonboard 845c (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sdw_stream_add_slave+0x44/0x380 [bus_soundwire] lr : sdw_stream_add_slave+0x44/0x380 [bus_soundwire] sp : ffff80008a2035c0 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 000000000000000 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 00000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8 Rastreo de llamadas: sdw_stream_add_slave+0x44/0x380 [bus de cable de sonido] wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x] snd_soc_dai_hw_params+0x3c/0xa4 __soc_pcm_hw_params+0x230/0x660 dpcm_be_dai_hw_params+0x1d0/0x3f8 dpcm_fe_dai_hw_params+0x98/0x268 snd_pcm_hw_params+0x124/0x460 snd_pcm_common_ioctl+0x998/0x16e8 snd_pcm_ioctl+0x34/0x58 __arm64_sys_ioctl+0xac/0xf8 invocar_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xe0 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Código: aa0403fb f9418400 9100e000 9400102f (f8420f22) ---[ fin de seguimiento 000000000000000 ]--- 0000000000006108 : 6108: d503233f paciasp 610c: a9b97bfd stp x29, x30, [sp, #-112]! 6110: 910003fd movimiento x29, movimiento rápido 6114: a90153f3 movimiento rápido x19, x20, [movimiento rápido, n.° 16] 6118: a9025bf5 movimiento rápido x21, x22, [movimiento rápido, n.° 32] 611c: aa0103f6 movimiento x22, x1 6120: 2a0303f5 movimiento rápido w21, w3 6124: a90363f7 movimiento rápido x23, x24, [movimiento rápido, n.° 48] 6128: aa0003f8 movimiento rápido x24, x0 612c: aa0203f7 movimiento rápido x23, x2 6130: a9046bf9 movimiento rápido x25, x26, [movimiento rápido, n.° 64] 6134: aa0403f9 mov x25, x4 <-- x4 copiado a x25 6138: a90573fb stp x27, x28, [sp, #80] 613c: aa0403fb mov x27, x4 6140: f9418400 ldr x0, [x0, #776] 6144: 9100e000 agrega x0, x0, #0x38 6148: 94000000 bl 0 614c: f8420f22 ldr x2, [x25, #32]! <-- desplazamiento 0x44 ^^^ Esto es 0x6108 + desplazamiento 0x44 desde el comienzo de sdw_stream_add_slave() donde ocurre la interrupción de datos. Se llama a wsa881x_hw_params() con stream = NULL y se pasa más adelante en el registro x4 (quinto argumento ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Establecer SDEV_OFFLINE cuando se apaga UFS. Hay un historial de interbloqueo si se realiza el reinicio al comienzo del arranque. SDEV_QUIESCE se estableció para todos los scsi_devices de LU por el apagado de UFS, y en ese momento el controlador de audio estaba esperando a blk_mq_submit_bio() sosteniendo un mutex_lock mientras leía el binario fw. Después de eso, ocurrió un problema de interbloqueo mientras el apagado del controlador de audio estaba esperando mutex_unlock de blk_mq_submit_bio(). Para resolver esto, establezca SDEV_OFFLINE para todas las LU excepto WLUN, de modo que cualquier E/S que se caiga después de un apagado de UFS devuelva un error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [apagado_dispositivo] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Rastreo de llamadas: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: intercambiador/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: intercambiador/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: intercambiador/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: intercambiador/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: intercambiador/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: intercambiador/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: intercambiador/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: intercambiador/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: intercambiador/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: intercambiador/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: intercambiador/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: intercambiador/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: intercambiador/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: intercambiador/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: intercambiador/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: intercambiador/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Rastreo de llamadas: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: intercambiador/0: 0] __submit_bio+0xb8/0x19c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: sondas: Eliminar el soporte roto de uprobe LDR (literal). Las funciones simulation_ldr_literal() y simulation_ldrsw_literal() no son seguras para usar con uprobes. Ambas funciones se escribieron originalmente para usar con kprobes y acceder a la memoria con accesos C simples. Cuando se agregó uprobes, se reutilizaron sin modificar a pesar de que no pueden acceder de manera segura a la memoria del usuario. Hay tres problemas clave: 1) Los accesos C simples no tienen entradas extable correspondientes y, por lo tanto, si encuentran un fallo, el kernel los tratará como accesos no intencionales a la memoria del usuario, lo que resultará en un BUG() que matará el hilo del kernel y probablemente conducirá a más problemas (por ejemplo, bloqueo o panic()). 2) Los accesos C simples están sujetos a HW PAN y SW PAN, y por lo tanto, cuando cualquiera de ellos está en uso, cualquier intento de simular un acceso a la memoria del usuario fallará. Por lo tanto, ni simulation_ldr_literal() ni simulation_ldrsw_literal() pueden hacer nada útil al simular una instrucción de usuario en cualquier sistema con HW PAN o SW PAN. 3) Los accesos C simples son privilegiados, ya que se ejecutan en el contexto del núcleo y, en la práctica, pueden acceder a un pequeño rango de direcciones virtuales del núcleo. Las instrucciones que simulan tienen un rango de +/-1 MiB y, dado que las instrucciones simuladas deben ser instrucciones de usuario en el rango de direcciones TTBR0, estas pueden direccionar el último MiB del rango de direcciones de TTBR1 envolviendo hacia abajo desde una dirección en el primer MiB del rango de direcciones TTBR0. En los núcleos contemporáneos, los últimos 8 MiB del rango de direcciones TTBR1 están reservados y los accesos a estos siempre fallarán, lo que significa que esto no es peor que (1). Históricamente, era teóricamente posible que el mapa lineal o vmemmap se derramara en los últimos 8 MiB del rango de direcciones TTBR1, pero en la práctica esto es extremadamente improbable que ocurra ya que esto requeriría: * Tener suficiente memoria física para llenar todo el mapa lineal hasta el último 1 MiB del rango de direcciones TTBR1. * Tener mala suerte con la aleatorización KASLR del mapa lineal de modo que la región poblada se superponga con el último 1 MiB del rango de direcciones TTBR. ... y en cualquier caso, si nos desbordáramos en la página final, habría problemas más grandes ya que la página final tendría alias con punteros de error. Prácticamente hablando, (1) y (2) son los grandes problemas. Dado que no ha habido informes de problemas desde que se introdujo el código roto, parece que nadie confía en sondear estas instrucciones con uprobes. Evite estos problemas al no permitir uprobes en LDR (literal) y LDRSW (literal), y al limitar el uso de simulation_ldr_literal() y simulation_ldrsw_literal() a kprobes. Los intentos de colocar uprobes en LDR (literal) y LDRSW (literal) serán rechazados ya que arm_probe_decode_insn() devolverá INSN_REJECTED. En el futuro, podemos considerar la introducción de compatibilidad con uprobes funcionales para estas instrucciones, pero esto requerirá un trabajo más significativo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige pci_for_each_dma_alias() incorrecto para dispositivos que no sean PCI Anteriormente, la función domain_context_clear() llamaba incorrectamente a pci_for_each_dma_alias() para configurar entradas de contexto para dispositivos que no sean PCI. Esto podría provocar bloqueos del kernel u otro comportamiento inesperado. Agregue una verificación para llamar solo a pci_for_each_dma_alias() para dispositivos PCI. Para dispositivos que no sean PCI, se llama a domain_context_clear_one() directamente.