Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: soluciona una posible pérdida de memoria en ice_gnss_tty_write(). El ice_gnss_tty_write() regresa directamente si falla la asignación write_buf, filtrando el cmd_buf. Corrija mediante cmd_buf gratuito si falla la asignación de write_buf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Agregar verificación para kzalloc Agregue la verificación para el valor de retorno de kzalloc para evitar la desreferencia al puntero NULL. Además, utilice la etiqueta goto para compartir el código limpio.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: elimina los bloqueos de rcu de los recursos del usuario. Las búsquedas de recursos del usuario utilizaron rcu para evitar dos átomos adicionales. Desafortunadamente, las rutas de rcu tenían errores y era fácil hacer que el controlador fallara al enviar búferes de comando desde dos subprocesos diferentes. Debido a que las búsquedas nunca aparecen en los perfiles de rendimiento, reemplácelas con un bloqueo de giro normal que corrige las ejecuciones en los accesos a esos recursos compartidos. Corrige los fallos del kernel en la prueba de esfuerzo vmwgfxexecution_búfer de IGT y los fallos observados en las aplicaciones que utilizan recursos compartidos.

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: drm/i915/gt: Limpieza de fallas parciales en el descubrimiento del motor Si abortamos la inicialización del controlador en medio del descubrimiento de gt/engine, algunos motores estarán completamente configurados y otros no. Esos motores configurados de forma incompleta solo tienen 'motor->liberación == NULL' y, por lo tanto, filtrarán cualquiera de los objetos comunes asignados. v2: - Suelta el ayudante destroy_pinned_context() por ahora. Realmente no vale la pena con un solo sitio de llamada en este momento. (Janusz)

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.