Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panthor: Bloquear XArray al obtener entradas para la VM De manera similar a el commit cac075706f29 ("drm/panthor: Corregir la ejecución al convertir el identificador de grupo en un objeto de grupo"), debemos usar el bloqueo interno de XArray al recuperar un puntero de VM desde allí. v2: Se eliminó parte del parche que intentaba proteger la obtención del puntero del montón de XArray, ya que esa operación está protegida por @pool->lock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: qcom-pmic: valor inicial de hdr_len/txbuf_len anterior Si la lectura de USB_PDPHY_RX_ACKNOWLEDGE_REG falla, entonces hdr_len y txbuf_len no se inicializan. Esta confirmación deja de imprimir valores no inicializados y datos engañosos/falsos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imagination: Romper un bucle de referencia de objeto Cuando se están limpiando los recursos restantes al cerrar el controlador, las asignaciones de VM pendientes pueden provocar una fuga de recursos, debido a un bucle de referencia de objeto, como se muestra a continuación, con cada objeto (o conjunto de objetos) haciendo referencia al objeto debajo de él: Objeto PVR GEM Cerca "terminada" del programador de GPU Cerca "programada" del programador de GPU Cerca "terminada" del controlador PVR Contexto PVR Contexto de VM PVR Asignaciones de VM PVR Objeto PVR GEM La referencia que tiene el Contexto de VM PVR en las asignaciones de VM es suave, en el sentido de que la liberación de las asignaciones de VM pendientes se realiza como parte de la destrucción del contexto de VM; no hay recuentos de referencia involucrados, como es el caso de todas las demás referencias en el bucle. Para romper el bucle de referencia durante la limpieza, libere las asignaciones de VM pendientes antes de destruir el Contexto PVR asociado con el contexto de VM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: Bloquear el chip TPM en tpm_pm_suspend() primero Establecer TPM_CHIP_FLAG_SUSPENDED al final de tpm_pm_suspend() puede ser arriesgado, ya que esto deja margen para que se llame a tpm_hwrng_read() mientras la operación está en progreso. El reciente informe de errores también proporciona evidencia de este comportamiento. Solucione esto bloqueando el chip TPM antes de comprobar cualquier chip->flags tanto en tpm_pm_suspend() como en tpm_hwrng_read(). Mueva la comprobación TPM_CHIP_FLAG_SUSPENDED dentro de tpm_get_random() para que siempre se compruebe solo cuando el bloqueo esté reservado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se elimina el bloqueo dma-resv de la máquina virtual en caso de error xe_sync_in_fence_get en IOCTL de ejecución. En caso de error, se deben eliminar todos los bloqueos antes de devolverlos al usuario. (seleccionado de el commit 7d1a4258e602ffdce529f56686925034c1b3b095)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se corrige una posible pérdida de cola de ejecución en la IOCTL de ejecución. En un par de lugares, después de que se busca una cola de ejecución, la IOCTL de ejecución devuelve errores de entrada sin descartar la referencia de la cola de ejecución. Se soluciona este problema asegurándose de descartar la referencia de la cola de ejecución en caso de error de entrada. (seleccionado de el commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: no filtrar un enlace al eliminar un AP Liberar el recurso de mapeo de enlaces al eliminar un AP. Esto afectó a los dispositivos que no admiten la API MLD (9260 y versiones anteriores). En esos dispositivos, no pudimos iniciar el AP nuevamente después de que ya se había iniciado y detenido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ar0521: no se produce un desbordamiento al comprobar los valores PLL Las comprobaciones PLL están comparando números enteros de 64 bits con números de 32 bits, según lo informado por Coverity. Según los valores de las variables, esto puede producirse un desbordamiento. Arréglelo asegurándose de que ambos lados de la expresión sean u64.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: Agregar comprobación de hash_key_length Agregue comprobación de hash_key_length en virtnet_probe() para evitar posibles errores fuera de los límites al configurar/leer la clave hash.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: corregir la condición de ejecución añadiendo el estado de sincronización intermedio del filtro Corrige una condición de ejecución en el controlador i40e que provoca que los filtros MAC/VLAN se corrompan y tengan fugas. Aborda el problema que se produce bajo una carga pesada cuando varios subprocesos modifican simultáneamente los filtros MAC/VLAN configurando mac y puerto VLAN. 1. El subproceso T0 asigna un filtro en i40e_add_filter() dentro de i40e_ndo_set_vf_port_vlan(). 2. El subproceso T1 libera simultáneamente el filtro en __i40e_del_filter() dentro de i40e_ndo_set_vf_mac(). 3. Posteriormente, i40e_service_task() llama a i40e_sync_vsi_filters(), que hace referencia a la memoria del filtro ya liberada, lo que provoca la corrupción. Pasos de reproducción: 1. Generar varios VF. 2. Aplique una carga pesada simultánea ejecutando operaciones paralelas para cambiar las direcciones MAC en las VF y cambiar las VLAN de puerto en el host. 3. Observe los errores en dmesg: "Error I40E_AQ_RC_ENOSPC al agregar filtros RX en VF XX, active manualmente la promiscuidad para VF XX". Código exacto para reproducción estable Intel no puede abrir el código fuente ahora. La solución implica implementar un nuevo estado de filtro intermedio, I40E_FILTER_NEW_SYNC, para el momento en que un filtro esté en una lista tmp_add_list. Estos filtros no se pueden eliminar de la lista hash directamente, sino que se deben eliminar mediante el proceso completo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mgb4: proteger el controlador contra spectre El rango de frecuencia se establece desde sysfs a través de frequency_range_store(), siendo vulnerable a spectre, como lo informó smatch: drivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: posible problema de spectre 'cmt_vals_in' [r] drivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: posible segunda mitad de spectre. 'reg_set' Arréglenlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: fix idpf_vc_core_init error path En un evento en el que se reinicia la plataforma que ejecuta el plano de control del dispositivo, se detecta un reinicio en el controlador. Libera todos los recursos y espera a que se complete el reinicio. Una vez que se realiza el reinicio, intenta reconstruir los recursos. En este momento, si el plano de control del dispositivo aún no se inició, el controlador agota el tiempo de espera en el mensaje virtchnl y vuelve a intentar establecer el buzón. En el flujo de reintento, el buzón se desinicializa, pero la cola de trabajo del buzón sigue activa y sondea el mensaje del buzón. Esto da como resultado el acceso a la cola de control liberada, lo que genera null-ptr-deref. Arréglelo desenrollando la cancelación de la cola de trabajo y la desinicialización del buzón en el orden inverso al que se inicializaron.