Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virt: tdx-guest: Just leak decrypted memory on unrecoverable errors En las máquinas virtuales CoCo, es posible que el host no confiable haga que set_memory_decrypted() falle de modo que se devuelva un error y se comparta la memoria resultante. Los llamadores deben tener cuidado de gestionar estos errores para evitar devolver memoria descifrada (compartida) al asignador de páginas, lo que podría provocar problemas funcionales o de seguridad. Filtra la memoria descifrada cuando set_memory_decrypted() falla y no necesitas imprimir un error ya que set_memory_decrypted() llamará a WARN_ONCE().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: rockchip: samsung-hdptx: Establecer drvdata antes de habilitar el PM en tiempo de ejecución En algunos casos, se puede invocar rk_hdptx_phy_runtime_resume() antes de que se ejecute platform_set_drvdata() en ->probe(), lo que genera una desreferencia de puntero NULL cuando se usa el retorno de dev_get_drvdata(). Asegúrese de que se llame a platform_set_drvdata() antes de devm_pm_runtime_enable().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: comprobar el valor de retorno de sock_recvmsg al drenar datos de clc Al recibir un mensaje de clc, la longitud del campo en smc_clc_msg_hdr indica que la longitud del mensaje debe recibirse de la red y que el valor no debe ser completamente confiable ya que es de la red. Una vez que el valor de la longitud excede el valor de buflen en la función smc_clc_wait_msg, puede encontrarse con un bucle muerto al intentar drenar los datos restantes que exceden buflen. Este parche verifica el valor de retorno de sock_recvmsg al drenar datos en caso de un bucle muerto en el drenaje.