Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: corregido el error de use after free en brcmf_cfg80211_detach Este es el parche candidato de CVE-2023-47233: https://nvd.nist.gov/vuln/detail /CVE-2023-47233 En el controlador brcm80211, comienza con la siguiente cadena de invocación para iniciar un trabajador de tiempo de espera: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg ->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); Si desconectamos el USB mediante hotplug, llamará a brcmf_usb_disconnect para realizar la limpieza. La cadena de invocación es: brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); Mientras que el activador de tiempo de espera aún puede estar ejecutándose. Esto provocará un error de use after free en cfg en brcmf_cfg80211_escan_timeout_worker. Soluciónelo eliminando el temporizador y cancelando el trabajador en brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: mantenga la eliminación del temporizador tal como está y cancele el trabajo justo antes de liberarlo]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdc-wdm: ejecución cercana entre lectura y cola de trabajo wdm_read() no puede ejecutarse consigo mismo. Sin embargo, en service_outstanding_interrupt() puede competir con la cola de trabajo, lo que puede desencadenarse mediante el manejo de errores. Por lo tanto, debemos asegurarnos de que el indicador WDM_RESPONDING no sólo esté configurado sino también probado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: swiotlb: corregida la doble asignación de ranuras debido a un manejo de alineación roto. Confirmación bbb73a103fbb ("swiotlb: corrija un barino en la corrección de verificación de alineación"), que fue una solución para la confirmación 0eee5ae10256 ( "swiotlb: corregir comprobaciones de alineación de ranuras"), provoca una regresión funcional con vsock en una máquina virtual mediante el rebote a través de un grupo DMA SWIOTLB restringido. Cuando virtio asigna las colas virtio para el dispositivo vsock usando dma_alloc_coherent(), la búsqueda de SWIOTLB puede devolver asignaciones de página no alineadas si 'area->index' quedó desalineado por una asignación anterior del búfer: # La dirección final entre paréntesis es la dirección de SWIOTLB devuelto a la persona que llama | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1653-1657/7168 (0x9832a800) Esto termina mal (normalmente corrupción del búfer y/o bloqueo) porque swiotlb_alloc() está esperando una página -asignación alineada y, por lo tanto, devuelve ciegamente un puntero a la 'struct page' correspondiente a la asignación, por lo que asigna dos veces la primera mitad (ranura de 2 KB) de la página de 4 KB. Solucione el problema tratando la alineación de asignación por separado de cualquier requisito de alineación adicional del dispositivo, utilizando el máximo de los dos como paso para buscar las ranuras del búfer y teniendo cuidado de garantizar un mínimo de alineación de página para búferes más grandes que una página. Esto también resuelve las fallos de asignación de swiotlb que ocurren debido a la inclusión de ~PAGE_MASK en 'iotlb_align_mask' para asignaciones grandes y que resultan en requisitos de alineación que exceden swiotlb_max_mapping_size().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: core: evitar índice negativo con acceso a matriz Commit 4d0c8d0aef63 ("mmc: core: usar mrq.sbc en ffu cerrado") asigna prev_idata = idatas[i - 1] , pero no comprueba que el iterador i sea mayor que cero. Arreglemos esto agregando una comprobación.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: soc:fsl:qbman: Desactiva siempre las interrupciones al tomar cgr_lock smp_call_function_single desactiva las IRQ al ejecutar la devolución de llamada. Para evitar interbloqueos, debemos desactivar las IRQ cuando llevemos cgr_lock a otro lugar. Esto ya lo hacen qman_update_cgr y qman_delete_cgr; arreglar los otros casilleros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/dm-raid: no llame a md_reap_sync_thread() directamente Actualmente, se llama a md_reap_sync_thread() desde raid_message() directamente sin mantener presionado 'reconfig_mutex', esto definitivamente no es seguro porque md_reap_sync_thread( ) puede cambiar muchos campos protegidos por 'reconfig_mutex'. Sin embargo, mantener 'reconfig_mutex' aquí sigue siendo problemático porque esto causará un punto muerto, por ejemplo, confirme 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock"). Solucione este problema usando stop_sync_thread() para cancelar el registro de sync_thread, como lo hizo md/raid.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: corregida la vida útil de la memoria del cursor bo. La sanitización se puede realizar mientras la actualización atómica aún está activa, lo que significa que la memoria adquirida en la actualización atómica no necesita ser invalidado por la limpieza. Los objetos del búfer en vmw_plane_state, en lugar de utilizar el map_and_cache incorporado, intentaban manejar ellos mismos la vida útil de la memoria asignada, lo que provocaba fallos. Utilice map_and_cache en lugar de intentar administrar la vida útil de los objetos del búfer retenidos por vmw_plane_state. Corrige los errores del kernel en kms_cursor_legacy forked-bo de IGT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/PM: drena las devoluciones de llamada inactivas en tiempo de ejecución antes de eliminar el controlador. Una condición de ejecución entre la devolución de llamada .runtime_idle() y la devolución de llamada .remove() en el controlador PCI rtsx_pcr conduce a un crash de kernel debido a un error de página no controlado [1]. El problema es que no se espera que rtsx_pci_runtime_idle() se ejecute después de llamar a pm_runtime_get_sync(), pero esto último realmente no garantiza eso. Solo garantiza que las devoluciones de llamada de suspensión y reanudación no se ejecutarán cuando regrese. Sin embargo, si ya se está ejecutando una devolución de llamada .runtime_idle() cuando se llama a pm_runtime_get_sync(), este último notará que el estado de PM en tiempo de ejecución del dispositivo es RPM_ACTIVE y regresará de inmediato sin esperar a que se complete el primero. De hecho, no puede esperar a que se complete .runtime_idle() porque puede ser llamado desde esa devolución de llamada (podría decirse que no tiene mucho sentido hacerlo, pero no está estrictamente prohibido). Por lo tanto, en general, quien proporciona una devolución de llamada .runtime_idle() debe protegerla para que no se ejecute en paralelo con cualquier código que se ejecute después de pm_runtime_get_sync(). [Tenga en cuenta que .runtime_idle() no se iniciará después de que pm_runtime_get_sync() haya regresado, pero puede continuar ejecutándose si comenzó antes.] Una forma de abordar esa condición de ejecución es llamar a pm_runtime_barrier() después de pm_runtime_get_sync() (no antes porque es necesario un valor distinto de cero del contador de uso de PM en tiempo de ejecución para evitar que se invoquen devoluciones de llamada de PM en tiempo de ejecución) para esperar a que se complete la devolución de llamada .runtime_idle() en caso de que se esté ejecutando en ese punto. Un lugar adecuado para hacerlo es pci_device_remove() que llama a pm_runtime_get_sync() antes de eliminar el controlador, por lo que también puede llamar a pm_runtime_barrier() posteriormente, lo que evitará que se produzca la ejecución en cuestión, no sólo en el controlador rtsx_pcr, sino en cualquier controlador PCI que proporcione devoluciones de llamada .runtime_idle().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corregida la corrupción durante el cambio de tamaño en línea Observamos una corrupción durante el cambio de tamaño en línea de un sistema de archivos de más de 16 TiB con un tamaño de bloque de 4k. Al tener más de 2 ^ 32 bloques, mke2fs desactiva resize_inode de forma predeterminada. El problema se puede reproducir en un sistema de archivos más pequeño por conveniencia desactivando explícitamente resize_inode. Un cambio de tamaño en línea a través de un límite de 8 GiB (el tamaño de un grupo de metabloques en esta configuración) conduce a una corrupción: dev=/dev/ # debería ser >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # soltar caché de página para forzar la recarga del bloque desde el disco echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equivale a 8 GiB de los cuales 2^15 es el número de bloques por grupo de bloques y 2^6 es el número de grupos de bloques que forman un metagrupo de bloques. La última suma de comprobación puede ser diferente dependiendo de cómo esté distribuido el archivo en los bloques físicos. La corrupción real ocurre en el bloque físico 63*2^15 = 2064384, que sería la ubicación de la copia de seguridad del descriptor de bloque del grupo de metabloques. Durante el cambio de tamaño en línea, el sistema de archivos se convertirá a meta_bg comenzando en s_first_meta_bg, que en el ejemplo es 2, es decir, todos los grupos de bloques después de 16 GiB. Sin embargo, en ext4_flex_group_add podríamos agregar grupos de bloques que aún no forman parte del primer metagrupo de bloques. En el reproductor logramos esto restando el tamaño de un grupo de bloques completo desde el punto donde comenzaría el grupo de metabloques. Esto debe tenerse en cuenta al actualizar los descriptores del grupo de bloques de respaldo para que sigan el diseño que no es meta_bg. La solución es agregar una prueba de si el grupo a agregar ya forma parte del grupo de metabloques o no.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/sev: corregidas las referencias de variables dependientes de la posición en el código de inicio. El código de inicio temprano se ejecuta desde una asignación de memoria 1:1, que difiere de la asignación a la que se vinculó el código y/. o reubicado para correr. Esta última asignación aún no está activa en este momento, por lo que las referencias de símbolos que dependen de ella fallarán. Dado que el kernel principal está construido sin -fPIC, las referencias a símbolos generalmente se emiten como absolutas, por lo que cualquier referencia de este tipo que ocurra en el código de inicio temprano bloqueará el kernel. Si bien se intentó solucionar este problema en el código de inicio inicial de SEV/SME, forzando el direccionamiento relativo a RIP para ciertas variables globales de SEV/SME mediante un ensamblaje en línea (consulte snp_cpuid_get_table(), por ejemplo), el direccionamiento relativo a RIP debe ser omnipresente. aplicado para las variables globales SEV/SME cuando se accede a ellas antes de las correcciones de la tabla de páginas. __startup_64() ya maneja este problema para variables globales seleccionadas que no son SEV/SME usando fixup_pointer(), que ajusta el puntero en relación con un argumento `physaddr`. Para evitar tener que pasar este argumento `physaddr` entre todas las funciones que necesitan aplicar correcciones de puntero, introduzca una macro RIP_RELATIVE_REF() que genera una referencia relativa a RIP a una variable global determinada. Se utiliza cuando es necesario para forzar accesos relativos a RIP a variables globales. Para fines de backport, este parche no intenta limpiar otras apariciones de este patrón, que involucran inline asm o fixup_pointer(). Estos se abordarán más adelante. [bp: llámelo "rip_rel_ref" en todas partes, como otros códigos acortan la "referencia relativa a rIP" y hacen que el contenedor ASM sea __always_inline. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/efistub: llame a los servicios de arranque en modo mixto en la pila del firmware. Normalmente, el código auxiliar de EFI llama a los servicios de arranque de EFI utilizando la pila que estaba activa cuando se ingresó el código auxiliar. Según la especificación UEFI, esta pila debe tener un tamaño mínimo de 128k; esto puede parecer grande, pero todo el procesamiento asíncrono y el manejo de eventos en EFI se ejecutan desde la misma pila, por lo que en la práctica se puede utilizar bastante espacio. En modo mixto, la situación es un poco diferente: el gestor de arranque llama al punto de entrada del código auxiliar EFI de 32 bits, que llama al punto de entrada de 32 bits del descompresor, donde se configura la pila de arranque, utilizando una asignación fija de 16k. Esta pila todavía está en uso cuando el código auxiliar EFI se inicia en modo de 64 bits, por lo que todas las llamadas al firmware EFI utilizarán la pila de arranque limitada del descompresor. Debido a la ubicación de la pila de arranque justo después del montón de arranque, cualquier desbordamiento de la pila pasa desapercibido. Sin embargo, la confirmación 5c4feadb0011983b ("x86/decompressor: Mover referencias de símbolos globales al código C") movió la definición del montón de arranque al código C, y ahora la pila de arranque se coloca justo en la base de BSS, donde cualquier desbordamiento dañará el final de la sección .data. Si bien sería posible solucionar este problema aumentando el tamaño de la pila de arranque, hacerlo afectaría a todos los sistemas x86, y los sistemas de modo mixto son una fracción pequeña (y cada vez menor) de la base instalada x86. En su lugar, registre el valor del puntero de la pila de firmware al ingresar desde el firmware de 32 bits y cambie a esta pila cada vez que se realice una llamada al servicio de arranque EFI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: marcar el gfn de destino de la instrucción atómica emulada como sucia Al emular un acceso atómico en nombre del invitado, marque el gfn de destino como sucio si se intenta realizar el CMPXCHG por KVM y no falla. Esto corrige un error por el cual KVM corrompe efectivamente la memoria del invitado durante la migración en vivo al escribir en la memoria del invitado sin informar al espacio de usuario que la página está sucia. Marcar la página como sucia se eliminó involuntariamente cuando el CMPXCHG emulado de KVM se convirtió para realizar un acceso de usuario. Antes de eso, KVM asignaba explícitamente la página invitada a la memoria del kernel y marcaba la página como sucia durante la fase de desasignación. Marque la página como sucia incluso si CMPXCHG falla, ya que los datos antiguos se vuelven a escribir en caso de fallo, es decir, la página aún está escrita. Se garantiza que el valor escrito será el mismo porque la operación es atómica, pero la ABI de KVM es que todas las escrituras se registran de forma sucia independientemente del valor escrito. Y lo que es más importante, eso es lo que hizo KVM antes de la confirmación del error. Felicitaciones enormes a las personas en la lista Cc (y a muchos otros), que hicieron todo el trabajo de clasificación y depuración. confirmación base: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64