Vulnerabilidades

En BnAudioPolicyService::onTransact de AudioPolicyService.cpp, existe una posible divulgación de información debido a datos no inicializados. Esto podría generar una divulgación de información local sin necesidad de privilegios de ejecución adicionales. No se necesita la interacción del usuario para la explotación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rpcrdma: Siempre liberar el xa_array de rpcrdma_device Dai señaló que xa_init_flags() en rpcrdma_add_one() debe tener un xa_destroy() coincidente en rpcrdma_remove_one() para liberar la memoria subyacente que el xarray podría haber acumulado durante la operación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: Se ha corregido la comprobación NULL frente a IS_ERR() en probe() La función iommu_paging_domain_alloc() no devuelve punteros NULL, sino punteros de error. Actualice la comprobación para que coincida.

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: 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: 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/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: 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: mm/thp: arregla el bloqueo y el nombre de la cola de separación diferida Los cambios recientes están poniendo más presión en las colas de separación diferida de THP: bajo carga revelando ejecucións de larga data, causando corrupciones de list_del, "Bad page state" y peores (mantengo ERRORES en ambos, por lo que generalmente no llego a ver qué tan mal terminan sin ellos). Los cambios recientes relevantes son mTHP de 6.8, mTHP swapout de 6.10 y mTHP swapin de 6.12, asignación de intercambio mejorada y división de THP infrautilizada. Antes de arreglar el bloqueo: cambia el nombre de folio_undo_large_rmappable() engañoso, que no deshace large_rmappable, a folio_unqueue_deferred_split(), que es lo que hace. Pero eso y su __callee fuera de línea son internos mm de usabilidad muy limitada: agrega comentario y WARN_ON_ONCEs para verificar el uso; y devuelve un bool para decir si una división diferida fue sacada de la cola, que luego se puede usar en WARN_ON_ONCEs alrededor de las verificaciones de seguridad (ahorrando a los llamadores las condicionales arcanas en __folio_unqueue_deferred_split()). Simplemente omite folio_unqueue_deferred_split() de free_unref_folios(), todos cuyos llamadores ahora lo llaman de antemano (y si alguno se olvida, bad_page() lo dirá) - excepto su llamador put_pages_list(), que en sí mismo ya no tiene ningún llamador (y se eliminará por separado). Swapout: mem_cgroup_swapout() ha estado restableciendo folio->memcg_data 0 sin verificar y sacar de la cola un folio THP de la lista de divisiones diferidas; lo cual es desafortunado, ya que split_queue_lock depende de memcg (cuando memcg está habilitado); por lo que swapout ha estado sacando de la cola dichos THP más tarde, al liberar el folio, usando el bloqueo de pgdat en su lugar: potencialmente corrompiendo la lista de memcg. __remove_mapping() ha congelado refcount a 0 aquí, por lo que no hay problema con llamar a folio_unqueue_deferred_split() antes de restablecer memcg_data. Eso se remonta a el commit 5.4 87eaceb3faa5 ("mm: thp: make deferred split reductioner memcg awareness"): que incluía una verificación en swapcache antes de agregar a la cola diferida, pero ninguna verificación en la cola diferida antes de agregar THP a swapcache. Eso funcionó bien con la secuencia habitual de eventos en la recuperación (aunque hubo un par de formas raras en las que un THP en la cola diferida podría haber sido intercambiado), pero el commit 6.12 dafff3f4c850 ("mm: dividir THP subutilizados") evita dividir THP subutilizados en la recuperación, lo que hace que los THP de swapcache en la cola diferida sean algo común. ¿Mantener la verificación en swapcache antes de agregar a la cola diferida? Sí: ya no es esencial, pero conserva el comportamiento existente y es probable que sea una optimización que valga la pena (vmstat mostró mucho más tráfico en la cola bajo carga de intercambio si se eliminó la verificación); actualice su comentario. Movimiento de Memcg-v1 (obsoleto): mem_cgroup_move_account() ha estado cambiando folio->memcg_data sin verificar y sacar de la cola un folio THP de la lista diferida, a veces corrompiendo "de" la lista de memcg, como swapout. Refcount no es cero aquí, por lo que folio_unqueue_deferred_split() solo se puede usar en un WARN_ON_ONCE para validar la corrección, que debe hacerse antes: mem_cgroup_move_charge_pte_range() primero intenta dividir el THP (la división, por supuesto, desencola), o lo omite si eso falla. No es ideal, pero se ha solicitado mover el cargo, y khugepaged debería reparar el THP más tarde: nadie quiere un nuevo código de desencola personalizado solo para este caso obsoleto. el commit 87eaceb3faa5 tenía el código para moverse de una lista diferida a otra (pero no era consciente de su inseguridad mientras refcount no sea 0); pero eso fue eliminado por el commit fac0516b5534 de la versión 5.6 ---- truncado -----

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: 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)