Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/cpum_sf: Controlar la eliminación de hotplug de la CPU durante el muestreo la gestión de la eliminación de hotplug de la CPU activa la siguiente secuencia de llamada de función: CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu() ... CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu() El controlador de hotplug de la CPU de muestreo s390 CPUMF invoca: s390_pmu_sf_offline_cpu() +--> cpusf_pmu_setup() +--> setup_pmc_cpu() +--> deallocate_buffers() Esta función anula la asignación de todos los búferes de datos de muestreo (SDB) asignados para esa CPU en la inicialización del evento. También borra el bit PMU_F_RESERVED. La CPU desaparece y no se puede muestrear. Mientras el evento sigue activo en la CPU eliminada, la compatibilidad con hot plug de eventos de CPU en el subsistema de rendimiento del núcleo activa las siguientes llamadas de función en la CPU eliminada: perf_event_exit_cpu() +--> perf_event_exit_cpu_context() +--> __perf_event_exit_context() +--> __perf_remove_from_context() +--> event_sched_out() +--> cpumsf_pmu_del() +--> cpumsf_pmu_stop() +--> hw_perf_event_update() para detener y eliminar el evento. Durante la eliminación del evento, el controlador del dispositivo de muestreo intenta leer las muestras restantes de los búferes de datos de muestra (SDB). Pero ya se han liberado (y es posible que se hayan reasignado). Esto puede provocar una situación de use after free, en cuyo caso es muy probable que las muestras no sean válidas. En el mejor de los casos, la memoria no se ha reasignado y aún contiene datos válidos. Solucione esta situación y compruebe si la CPU sigue en estado reservado (bit PMU_F_RESERVED activado). En este caso, los SDB no se han liberado y contienen datos válidos. Esto siempre ocurre cuando se elimina el evento (y no se ha producido ninguna desconexión en caliente de la CPU). Si el bit PMU_F_RESERVED no está activado, los búferes SDB desaparecen.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jffs2: evitar la corrupción de la memoria de descompresión de rtime La rutina de descompresión de rtime no comprueba completamente los límites durante la totalidad del paso de descompresión y puede dañar la memoria fuera del búfer de descompresión si los datos comprimidos están dañados. Esto agrega la verificación requerida para evitar este modo de falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: ptrace: arreglo de SETREGSET parcial para NT_ARM_TAGGED_ADDR_CTRL Actualmente, tagged_addr_ctrl_set() no inicializa la variable temporal 'ctrl', y una llamada a SETREGSET con una longitud de cero la dejará sin inicializar. En consecuencia, tagged_addr_ctrl_set() consumirá un valor arbitrario, lo que potencialmente filtrará hasta 64 bits de memoria de la pila del kernel. La lectura está limitada a una ranura específica en la pila, y el problema no proporciona un mecanismo de escritura. Como set_tagged_addr_ctrl() solo acepta valores donde los bits [63:4] sean cero y rechaza otros valores, un intento de SETREGSET parcial tendrá éxito o fallará aleatoriamente dependiendo del valor del valor no inicializado, y la exposición es significativamente limitada. Solucione esto inicializando el valor temporal antes de copiar el conjunto de registros desde el espacio de usuario, como para otros conjuntos de registros (por ejemplo, NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). En el caso de una escritura de longitud cero, se conservará el valor existente de la dirección etiquetada ctrl. El conjunto de registros NT_ARM_TAGGED_ADDR_CTRL solo es visible en la vista user_aarch64_view utilizada por una tarea nativa de AArch64 para manipular otra tarea nativa de AArch64. Como get_tagged_addr_ctrl() solo devuelve un valor de error cuando se llama para una tarea de compatibilidad, tagged_addr_ctrl_get() y tagged_addr_ctrl_set() nunca deben observar un valor de error de get_tagged_addr_ctrl(). Agregue un WARN_ON_ONCE() a ambos para indicar que dicho error sería inesperado y que la gestión de errores no falta en ninguno de los casos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/dp_mst: Se soluciona el restablecimiento del estado de recepción del mensaje después de la eliminación de la topología Si se elimina la topología MST durante la recepción de un mensaje de banda lateral de respuesta de baja de MST o de solicitud de subida de MST, los estados drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv podrían restablecerse desde un hilo mediante drm_dp_mst_topology_mgr_set_mst(false), compitiendo con la lectura/análisis del mensaje desde otro hilo mediante drm_dp_mst_handle_down_rep() o drm_dp_mst_handle_up_req(). La competencia es posible ya que el lector/analizador no mantiene ningún bloqueo mientras accede al estado de recepción. Esto, a su vez, puede provocar una corrupción de memoria en el lector/analizador, como se describe en el commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check"). Corrija lo anterior restableciendo el estado de recepción del mensaje si es necesario antes de leer/analizar un mensaje. Otra solución sería mantener el bloqueo drm_dp_mst_topology_mgr::lock durante toda la duración de la recepción/análisis del mensaje en drm_dp_mst_handle_down_rep() y drm_dp_mst_handle_up_req(), sin embargo, esto requeriría un cambio mayor. Dado que la corrección también es necesaria para la versión estable, se opta por la solución más simple en este parche.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: imx6: Se corrige la compatibilidad con suspender/reanudar en i.MX6QDL La funcionalidad de suspender/reanudar actualmente está rota en la plataforma i.MX6QDL, como se documenta en la errata de NXP (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf Este parche soluciona el problema al compartir la mayoría de las secuencias de suspensión/reanudación utilizadas por otros dispositivos i.MX, al tiempo que evita las modificaciones en los registros críticos que interrumpen la funcionalidad PCIe. Apunta al mismo problema que la siguiente confirmación descendente: https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995 A diferencia de la confirmación descendente, este parche también restablece el dispositivo PCIe conectado si es posible. Sin este reinicio, ciertos controladores, como ath10k o iwlwifi, se bloquearán al reanudar. El reinicio del dispositivo también lo realiza el controlador en otras plataformas i.MX, lo que hace que este parche sea coherente con las prácticas existentes. Al reanudar, el núcleo se bloqueará y mostrará un error. Aquí hay un ejemplo del error encontrado con el controlador ath10k: ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944 Sin este parche, la suspensión/reinicio fallará en los dispositivos i.MX6QDL si hay un dispositivo PCIe conectado. [kwilczynski: registro de confirmaciones, etiqueta agregada para versiones estables]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/entry: Marcar entradas de IRQ para corregir advertencias del depósito de pila El depósito de pila filtra todo lo que esté fuera del contexto de interrupción superior como una parte poco interesante o irrelevante de los seguimientos de pila. Esto ayuda con la desduplicación del seguimiento de pila, evitando una explosión de seguimientos de pila guardados que comparten la misma ruta de código de contexto de IRQ pero que se originan en diferentes puntos interrumpidos aleatoriamente, agotando eventualmente el depósito de pila. El filtrado utiliza in_irqentry_text() para identificar funciones dentro de las secciones .irqentry.text y .softirqentry.text, que luego se convierten en las últimas entradas del seguimiento de pila que se guardan. Si bien __do_softirq() se coloca en la sección .softirqentry.text por código común, completar .irqentry.text es específico de la arquitectura. Actualmente, la sección .irqentry.text en s390 está vacía, lo que impide el filtrado y la deduplicación del depósito de pila y podría generar advertencias como: El depósito de pila alcanzó la capacidad límite ADVERTENCIA: CPU: 0 PID: 286113 en lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 con PREEMPT y KASAN habilitados. Solucione esto moviendo los controladores de interrupción IO/EXT de .kprobes.text a la sección .irqentry.text y actualizando la lista negra de kprobes para incluir la sección .irqentry.text. Esto se hace solo para interrupciones asincrónicas y explícitamente no para verificaciones de programa, que son sincrónicas y donde es importante preservar el contexto más allá de la verificación de programa. A pesar de que las verificaciones de máquina están algo en el medio, son extremadamente raras y preservar el contexto cuando sea posible también es valioso. Los SVC y las interrupciones de reinicio no son relevantes, uno siempre se encuentra en el límite del espacio del usuario y el otro es algo que ocurre una sola vez. El filtrado de entradas IRQ también se utiliza de manera opcional en el gráfico de funciones ftrace, donde se aplica la misma lógica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: memalloc: prefer dma_mapping_error() over explicit address checking Con CONFIG_DMA_API_DEBUG habilitado, se observa la siguiente advertencia: DMA-API: snd_hda_intel 0000:03:00.1: el controlador del dispositivo no pudo verificar el mapa error[dirección del dispositivo=0x00000000ffff0000] [tamaño=20480 bytes] [mapped as single] ADVERTENCIA: CPU: 28 PID: 2255 en kernel/dma/debug.c:1036 check_unmap+0x1408/0x2430 CPU: 28 UID: 42 PID: 2255 Comm: wireplumber Tainted: GWL 6.12.0-10-133577cad6bf48e5a7848c4338124081393bfe8a+ #759 debug_dma_unmap_page+0xe9/0xf0 snd_dma_wc_free+0x85/0x130 [snd_pcm] snd_pcm_lib_free_pages+0x1e3/0x440 [snd_pcm] snd_pcm_common_ioctl+0x1c9a/0x2960 [snd_pcm] snd_pcm_ioctl+0x6a/0xc0 [snd_pcm] ... Verifique las direcciones DMA devueltas utilizando el asistente especializado dma_mapping_error() que generalmente se recomienda para este propósito en Documentation/core-api/dma-api.rst.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Se corrige el estado de PHY de las páginas de configuración corruptas en sysfs El controlador, a través del transporte SAS, expone una interfaz sysfs para habilitar o deshabilitar los PHY en una configuración de controlador o expansor. Cuando se deshabilitan y habilitan varios PHY en rápida sucesión, las páginas de configuración persistentes y actuales relacionadas con la unidad SAS IO o las páginas del expansor SAS podrían corromperse. Utilice una memoria independiente para cada solicitud de configuración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: hda-dai: No libere el enlace DMA en STOP El linkDMA no debe liberarse en el disparador de detención ya que podría ocurrir un reinicio de transmisión sin cerrar la transmisión. Esto deja un corto tiempo para que otras transmisiones "roben" el linkDMA desde que se ha liberado. Este problema no es fácil de reproducir en condiciones normales ya que generalmente después de detener la transmisión se cierra, o se reinicia la misma transmisión, pero si otra transmisión se interpuso entre la detención y el inicio, como esto: aplay -Dhw:0,3 -c2 -r48000 -fS32_LE /dev/zero -d 120 CTRL+z aplay -Dhw:0,0 -c2 -r48000 -fS32_LE /dev/zero -d 120 entonces los canales de enlace DMA se mezclarán, lo que provocará un error o bloqueo del firmware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el error de atomicidad de transacciones al habilitar cuotas simples. Establezca el bit de incompatibilidad de squota antes de confirmar la transacción que habilita la función. Con la configuración CONFIG_BTRFS_ASSERT habilitada, se produce un error de afirmación con respecto a la función de cuota simple. [5.596534] Error de afirmación: btrfs_fs_incompat(fs_info, SIMPLE_QUOTA), en fs/btrfs/qgroup.c:365 [5.597098] ------------[ corte aquí ]------------ [5.597371] ¡ERROR del kernel en fs/btrfs/qgroup.c:365! [5.597946] CPU: 1 UID: 0 PID: 268 Comm: montaje No contaminado 6.13.0-rc2-00031-gf92f4749861b #146 [5.598450] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 [5.599008] RIP: 0010:btrfs_read_qgroup_config+0x74d/0x7a0 [5.604303] [5.605230] ? btrfs_read_qgroup_config+0x74d/0x7a0 [5.605538] ? asm_exc_invalid_op+0x1f/0x30 [5.606441] ? btrfs_read_qgroup_config+0x74d/0x7a0 [5.606741] ? btrfs_read_qgroup_config+0x74d/0x7a0 [5.607038] ? intentar_activar+0x317/0x760 [5.607286] abrir_ctree+0xd9c/0x1710 [5.607509] btrfs_get_tree+0x58a/0x7e0 [5.608002] vfs_get_tree+0x2e/0x100 [5.608224] montaje_fc+0x16/0x60 [5.608420] btrfs_get_tree+0x2f8/0x7e0 [5.608897] vfs_get_tree+0x2e/0x100 [5.609121] montaje_ruta+0x4c8/0xbc0 [5.609538] __x64_sys_mount+0x10d/0x150 El problema se puede reproducir fácilmente utilizando el siguiente reproductor: root@q:linux# cat repro.sh set -e mkfs.btrfs -q -f /dev/sdb mount /dev/sdb /mnt/btrfs btrfs quota enable -s /mnt/btrfs umount /mnt/btrfs mount /dev/sdb /mnt/btrfs El problema es que al habilitar cuotas, en btrfs_quota_enable(), configuramos BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE en fs_info->qgroup_flags y lo persistimos en la raíz de cuotas en el elemento con la clave BTRFS_QGROUP_STATUS_KEY, pero solo configuramos el bit de incompatibilidad BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA después de que confirmamos la transacción utilizada para habilitar la cuota simple. Esto significa que si después de esa confirmación de transacción desmontamos el sistema de archivos sin iniciar y confirmar ninguna otra transacción, o tenemos un corte de energía, la próxima vez que montemos el sistema de archivos encontraremos el indicador BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE establecido en el elemento con la clave BTRFS_QGROUP_STATUS_KEY pero no encontraremos el bit de incompatibilidad BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA establecido en el superbloque, lo que desencadena un error de aserción en: btrfs_read_qgroup_config() -> qgroup_read_enable_gen() Para solucionar este problema, configure el indicador BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA inmediatamente después de configurar BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE. Esto garantiza que ambos indicadores se vacíen en el disco dentro de la misma transacción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: megaraid_sas: Corrección de un posible bloqueo Esto corrige una advertencia de "posible dependencia de bloqueo circular detectada" CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex); Solucione esto liberando temporalmente el reset_mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: oa_tc6: arregla la condición de ejecución de tx skb entre punteros de referencia Hay dos punteros skb para administrar los tx skb en cola desde la pila n/w. El puntero waiting_tx_skb apunta al tx skb que necesita ser procesado y el puntero progress_tx_skb apunta al tx skb que está siendo procesado. El hilo SPI prepara los fragmentos de datos de tx desde el tx skb apuntado por el puntero progress_tx_skb. Cuando se procesa el tx skb apuntado por progress_tx_skb, el tx skb apuntado por progress_tx_skb se asigna a progress_tx_skb y el puntero waiting_tx_skb se asigna con NULL. Siempre que haya un nuevo skb tx de la pila n/w, se asignará al puntero waiting_tx_skb si es NULL. Puesta en cola y procesamiento de un skb tx gestionado en dos subprocesos diferentes. Considere un escenario donde el subproceso SPI procesó un going_tx_skb y mueve el siguiente skb tx del puntero waiting_tx_skb al puntero going_tx_skb sin hacer ninguna comprobación NULL. En este momento, si el puntero waiting_tx_skb es NULL, entonces el puntero going_tx_skb también se asigna con NULL. Después de eso, si un nuevo skb tx se asigna al puntero waiting_tx_skb por la pila n/w y existe la posibilidad de sobrescribir el puntero skb tx con NULL en el subproceso SPI. Finalmente, uno de los skb tx quedará como sin gestionar, lo que resultará en la pérdida de paquetes y pérdida de memoria. - Considere el siguiente escenario donde el TXC informado de la transferencia anterior es 10 y progress_tx_skb contiene una trama Ethernet de transmisión que se puede transportar en 20 TXC y waiting_tx_skb sigue siendo NULL. tx_credits = 10; /* 21 se completan en la transferencia anterior */ progress_tx_skb = 20; waiting_tx_skb = NULL; /* Sigue siendo NULL */ - Entonces, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) se vuelve verdadero. - Después de oa_tc6_prepare_spi_tx_buf_for_tx_skbs() progress_tx_skb = 10; waiting_tx_skb = NULL; /* Sigue siendo NULL */ - Realizar transferencia SPI. - Procesar el búfer de recepción SPI para obtener el TXC de los pies de página. - Ahora supongamos que los 21 TXC previamente completados se liberan, por lo que estamos listos para transportar los siguientes 10 fragmentos de tx restantes desde progress_tx_skb. tx_credits = 21; progress_tx_skb = 10; waiting_tx_skb = NULL; - Entonces, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) se vuelve verdadero nuevamente. - En oa_tc6_prepare_spi_tx_buf_for_tx_skbs() progress_tx_skb = NULL; waiting_tx_skb = NULL; - Ahora, el siguiente caso malo podría ocurrir, Thread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler) --------------------------- ----------------------------------- - si waiting_tx_skb es NULL - si going_tx_skb es NULL - going_tx_skb = waiting_tx_skb - waiting_tx_skb = skb - waiting_tx_skb = NULL ... - going_tx_skb = NULL - si waiting_tx_skb es NULL - waiting_tx_skb = skb Para superar el problema anterior, proteja el movimiento de la referencia tx skb del puntero waiting_tx_skb al puntero going_tx_skb y asigne el nuevo tx skb al puntero waiting_tx_skb, de modo que el otro hilo no pueda acceder al puntero waiting_tx_skb hasta que el hilo actual complete el movimiento de la referencia tx skb de manera segura.