Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm/dpu: corrige la pérdida de memoria en msm_mdss_parse_data_bus_icc_path of_icc_get() asigna recursos para la ruta1, debemos liberarlos cuando ya no los necesitemos. Retorno anticipado cuando IS_ERR_OR_NULL(ruta0) puede filtrar la ruta1. Posponga la obtención de la ruta 1 para solucionar este problema. Remiendo: https://patchwork.freedesktop.org/patch/514264/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: Intel: sof-nau8825: corrige el desbordamiento del alias del módulo La longitud máxima del nombre para una entrada platform_device_id es de 20 caracteres, incluido el byte NUL final. El archivo sof_nau8825.c excede eso, lo que provoca un oscuro mensaje de error: sound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: codificación de caracteres ilegal en cadena literal [-Werror,- Codificación de fuente válida de Win] MODULE_ALIAS("plataforma:adl_max98373_nau8825"); ^~~~ include/linux/module.h:168:49: nota: ampliado desde la macro 'MODULE_ALIAS' ^~~~~~ include/linux/module.h:165:56: nota: ampliado desde la macro 'MODULE_INFO' ^~~~ include/linux/moduleparam.h:26:47: nota: ampliado desde la macro '__MODULE_INFO' = __MODULE_INFO_PREFIX __stringify(tag) "=" info No pude entender cómo hacer que el módulo sea lo suficientemente robusto para manejar esto mejor, pero como solución rápida, usar nombres ligeramente más cortos que sigan siendo únicos evita el problema de compilación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: storvsc: corrige la fuga del búfer de rebote swiotlb en una VM confidencial storvsc_queuecommand() asigna la lista de dispersión/recopilación usando scsi_dma_map(), que en una VM confidencial asigna buffers de rebote swiotlb. Si el envío de E/S falla en storvsc_do_io(), la E/S normalmente se reintenta mediante código de nivel superior, pero la memoria del búfer de rebote nunca se libera. La causa más común de falla en el envío de E/S es un búfer de anillo de canal VMBus lleno, lo cual no es infrecuente bajo cargas de E/S elevadas. Con el tiempo, se pierden suficientes memorias del búfer de rebote como para que la máquina virtual confidencial no pueda realizar ninguna E/S. El mismo problema puede surgir en una máquina virtual no confidencial con el parámetro de arranque del kernel swiotlb=force. Solucione este problema haciendo scsi_dma_unmap() en el caso de un error de envío de E/S, lo que libera la memoria del búfer de rebote.

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: regulator: da9211: Usar irq handler cuando esté listo Si el sistema no viene del reset (como cuando es kexec()), es posible que el regulador tenga una IRQ esperándonos. Si habilitamos el controlador IRQ antes de que sus estructuras estén listas, fallamos. Este parche corrige: [1.141839] No se puede manejar la lectura del kernel desde una memoria ilegible en la dirección virtual 0000000000000078 [1.316096] Rastreo de llamadas: [1.316101] blocking_notifier_call_chain+0x20/0xa8 [ 1.322757] cpu cpu0: suministros ficticios no permitidos para solicitudes exclusivas [ 1.327 823] regulador_notificador_call_chain +0x1c/0x2c [ 1.327825] da9211_irq_handler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/core: corrige el error de use-after-free en dup_user_cpus_ptr() Desde el commit 07ec77a1d4e8 ("sched: permitir que la afinidad de la CPU de la tarea se restrinja en sistemas asimétricos"), la configuración y La limpieza de user_cpus_ptr se realiza en pi_lock para la arquitectura arm64. Sin embargo, dup_user_cpus_ptr() accede a user_cpus_ptr sin ninguna protección de bloqueo. Dado que sched_setaffinity() puede invocarse desde otro proceso, el proceso que se está modificando puede estar pasando por fork() al mismo tiempo. Cuando se corre con la limpieza de user_cpus_ptr en __set_cpus_allowed_ptr_locked(), puede llevar a una liberación posterior del usuario y posiblemente a una liberación doble en el kernel arm64. El commit 8f9ea86fdf99 ("programación: conservar siempre la máscara de CPU solicitada por el usuario") soluciona este problema ya que user_cpus_ptr, una vez configurado, nunca se borrará durante la vida de una tarea. Sin embargo, este error se reintrodujo en el commit 851a723e45d1 ("sched: borrar siempre user_cpus_ptr en do_set_cpus_allowed()") que permite borrar user_cpus_ptr en do_set_cpus_allowed(). Esta vez afectará a todos los arcos. Corrija este error borrando siempre el user_cpus_ptr de la tarea recién clonada/bifurcada antes de que comience el proceso de copia y verifique el estado de user_cpus_ptr de la tarea fuente en pi_lock. Nota para las versiones estables: este parche no se aplicará a las versiones estables. Simplemente copie la nueva función dup_user_cpus_ptr().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/arm-smmu-v3: no cancelar el registro al apagar. Similar a SMMUv2, este controlador llama a iommu_device_unregister() desde la ruta de apagado, lo que elimina los grupos IOMMU sin coordinación alguna. con sus usuarios: los métodos de apagado son opcionales en los controladores de dispositivos. Esto puede provocar desreferencias de puntero NULL en las llamadas API DMA de esos controladores, o algo peor. En lugar de llamar al arm_smmu_device_remove() completo desde arm_smmu_device_shutdown(), seleccionemos solo la llamada a la función relevante - arm_smmu_device_disable() - más o menos lo inverso de arm_smmu_device_reset() - y llamemos solo eso desde la ruta de apagado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/arm-smmu: no cancelar el registro al apagar Michael Walle dice que notó el siguiente seguimiento de pila mientras realizaba un apagado con "reboot -f". Sugiere que tuvo "suerte" y dio en el lugar correcto para el reinicio mientras había una transmisión de paquetes en vuelo. No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000098 CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 6.1.0-rc5-00088-gf3600ff8e322 #1930 Nombre de hardware: Kontron KBox A-230-LS (DT) pc: iommu_get_dma_domain+0x14/0x20 lr: iommu_dma_map_page+0x9c/0x254 Rastreo de llamadas: iommu_get_dma_domain+0x14/0x20 dma_map_page_attrs+0x1ec/0x250 enetc_start_xmit+0x14c/0x10b0 enetc_xmit+0x 60/0xdc dev_hard_start_xmit+0xb8/0x210 sch_direct_xmit+0x11c/0x420 __dev_queue_xmit+0x354 /0xb20 ip6_finish_output2+0x280/0x5b0 __ip6_finish_output+0x15c/0x270 ip6_output+0x78/0x15c NF_HOOK.constprop.0+0x50/0xd0 mld_sendpack+0x1bc/0x320 mld_ifc_work+0x1d8/0x4d c proceso_one_work+0x1e8/0x460 trabajador_thread+0x178/0x534 kthread+0xe0/ 0xe4 ret_from_fork+0x10/0x20 Código: d503201f f9416800 d503233f d50323bf (f9404c00) ---[ end trace 00000000000000000 ]--- Pánico del kernel - no se sincroniza: Ups: excepción fatal en la interrupción Esto parece ser reproducible cuando la placa tiene una IP dirección, se inunda el ping desde otro host y se utiliza "reboot -f". La siguiente es una manifestación más del problema: $ reboot -f kvm: saliendo de la virtualización de hardware cfg80211: no se pudo cargar regulator.db arm-smmu 5000000.iommu: deshabilitando la traducción sdhci-esdhc 2140000.mmc: eliminando del grupo iommu 11 sdhci- esdhc 2150000.mmc: Eliminación del grupo iommu 12 fsl-edma 22c0000.dma-controller: Eliminación del grupo iommu 17 dwc3 3100000.usb: Eliminación del grupo iommu 9 dwc3 3110000.usb: Eliminación del grupo iommu 10 ahci-qoriq 3200000.sata : Eliminación de iommu grupo 2 fsl-qdma 8380000.dma-controller: Eliminación de iommu grupo 20 plataforma f080000.display: Eliminación de iommu grupo 0 etnaviv-gpu f0c0000.gpu: Eliminación de iommu grupo 1 etnaviv etnaviv: Eliminación de iommu grupo 1 caam_jr 8010000.jr: Eliminando del grupo iommu 13 caam_jr 8020000.jr: Eliminando del grupo iommu 14 caam_jr 8030000.jr: Eliminando del grupo iommu 15 caam_jr 8040000.jr: Eliminando del grupo iommu 16 fsl_enetc 0000:00:00.0: Eliminando de iommu grupo 4 arm-smmu 5000000.iommu: ID de transmisión desconocida bloqueada 0x429; arranque con "arm-smmu.disable_bypass=0" para permitir, pero esto puede tener implicaciones de seguridad arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000 fsl_enetc 0000:00 :00.1: Eliminación del grupo 5 de Iommu arm-smmu 5000000.iommu: ID de transmisión desconocida bloqueada 0x429; arranque con "arm-smmu.disable_bypass=0" para permitir, pero esto puede tener implicaciones de seguridad arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000 arm-smmu 5000000. iommu: ID de transmisión desconocida bloqueada 0x429 ; arranque con "arm-smmu.disable_bypass=0" para permitir, pero esto puede tener implicaciones de seguridad arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000 fsl_enetc 0000:00 :00.2: Eliminación del grupo 6 de Iommu fsl_enetc_mdio 0000:00:00.3: Eliminación del grupo iommu 8 mscc_felix 0000:00:00.5: Eliminación del grupo iommu 3 fsl_enetc 0000:00:00.6: Eliminación del grupo iommu 7 pcieport 0001:00:00.0: Eliminación del grupo iommu 1 8 brazos- smmu 5000000.iommu: ID de transmisión desconocida bloqueada 0x429; arranque con "arm-smmu.disable_bypass=0" para permitir, pero esto puede tener implicaciones de seguridad arm-smmu 5000000.iommu: GFSR 0x00000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000 pcieport 0002:00:00 .0: ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ixgbe: repara la fuga de recuento de dispositivos pci Como dice el comentario de pci_get_domain_bus_and_slot(), devuelve un dispositivo PCI con el recuento de referencia incrementado, cuando termine de usarlo, la persona que llama debe disminuir el recuento de referencias en llamando a pci_dev_put(). En ixgbe_get_first_secondary_devfn() y ixgbe_x550em_a_has_mii(), se llama a pci_dev_put() para evitar fugas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64/mm: corrige file_map_count incorrecto para pmd no válido. La verificación de la tabla de páginas activa BUG_ON() inesperadamente cuando se divide una página enorme: ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/page_table_check.c:119! Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer vacío) Módulos vinculados en: CPU: 7 PID: 210 Comm: transhuge-stres No contaminado 6.1.0-rc3+ #748 Nombre de hardware: linux ,dummy-virt (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: page_table_check_set.isra.0+0x398/0x468 lr: page_table_check_set.isra.0+0x1c0/0x468 [...] Rastreo de llamadas: page_table_check_set.isra.0+0x398/0x468 __page_table_check_pte_set+0x160/0x1c0 __split_huge_pmd_locked+0x900/0x1648 __split_huge_pmd+0x28c/0x3b8 unmap_page_range+0x428/0x858 single_vma+0xf4/0x1c8 zap_page_range+0x2b0/0x410 madvise_vma_behavior+0xc44 /0xe78 do_madvise+0x280/0x698 __arm64_sys_madvise+0x90/0xe8 invoke_syscall.constprop.0+0xdc/0x1d8 do_el0_svc+0xf4/0x3f8 el0_svc+0x58/0x120 el0t_64_sync_handler+0x b8/0xc0 el0t_64_sync+0x19c/0x1a0 [...] En arm64, pmd_leaf () devolverá verdadero incluso si el pmd no es válido debido a la verificación pmd_present_invalid(). Entonces, en pmdp_invalidate() file_map_count no solo disminuirá una vez sino que también aumentará una vez. Luego, en set_pte_at(), file_map_count aumenta nuevamente y, por lo tanto, activa BUG_ON() inesperadamente. Agregue !pmd_present_invalid() check in pmd_user_accessible_page() para solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dp: no complete dp_aux_cmd_fifo_tx() si irq no es para transferencia auxiliar. Hay 3 posibles fuentes de interrupción que son manejadas por el controlador DP, HPDstatus, los cambios de estado del controlador y Aux. transacción de lectura/escritura. En cada irq, el controlador DP debe verificar el estado isr de cada fuente de interrupción y atender la interrupción si sus bits de estado isr muestran que hay interrupciones pendientes. Existe una posible condición de ejecución que puede ocurrir en la implementación actual del controlador aux isr, ya que siempre está completo dp_aux_cmd_fifo_tx(), incluso irq no es para transacciones de lectura o escritura auxiliar. Esto puede causar que la transacción de lectura auxiliar regrese prematuramente si la lectura de datos auxiliares del host está en medio de la espera de que el receptor complete la transferencia de datos al host mientras ocurre la irq. Esto hará que el búfer de recepción del host contenga datos inesperados. Este parche soluciona este problema verificando aux isr y regresa inmediatamente al controlador aux isr si no hay ningún bit de estado isr establecido. Actualmente hay un informe de error que indica que la corrupción de eDP edid ocurre durante el inicio del sistema. Después de una larga depuración, descubrí que la interrupción VIDEO_READY se activaba continuamente durante el inicio del sistema, lo que provocaba que dp_aux_isr() completara dp_aux_cmd_fifo_tx() prematuramente para recuperar datos del búfer de hardware auxiliar que aún no contiene la transferencia completa de datos desde el receptor. Esto provocó corrupción. A continuación se muestra la firma en los registros del kernel cuando ocurre un problema, EDID tiene el panel de encabezado corrupto-simple-dp-aux aux-aea0000.edp: No se pudo identificar el panel a través de EDID Cambios en v2: - complete si (ret == IRQ_HANDLED) ay dp-aux_isr() - agregar más texto de confirmación Cambios en v3: - agregar Stephen sugerido - dp_aux_isr() devolver IRQ_XXX a la persona que llama - dp_ctrl_isr() devolver IRQ_XXX a la persona que llama Cambios en v4: - dividir en dos parches Cambios en v5: - eliminar línea vacía entre etiquetas Cambios en v6: - eliminar "eso" adicional y línea fija de más de 75 caracteres en el texto de confirmación Patchwork: https://patchwork.freedesktop.org/patch/516121/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/virtio: corrige la creación del identificador GEM. El espacio de usuario UAF puede adivinar el valor del identificador e intentar acelerar la creación de objetos GEM con el cierre del identificador, lo que resulta en un use-after-free si desreferenciamos el objeto después de soltar la referencia del identificador. Por esa razón, la eliminación de la referencia del identificador debe realizarse *después* de que hayamos terminado de desreferenciar el objeto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gsmi: corrige null-deref en gsmi_get_variable Podemos obtener variables EFI sin recuperar el atributo, por lo que debemos permitir eso en gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access Layer") agregó una nueva llamada get_variable con attr=NULL, lo que desencadena pánico en gsmi.