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 writeTypedArrayList y readTypedArrayList de Parcel.java, existe una posible escalada de privilegios debido a una confusión de tipos. Esto podría generar una escalada local de privilegios sin necesidad de permisos de ejecución adicionales. No se necesita interacción del usuario para la explotación.

En ResStringPool::setTo de ResourceTypes.cpp, es posible que un atacante controle que el valor de mStringPoolSize esté fuera de los límites, lo que provoca la divulgación de información.

En impeg2d_mc_fullx_fully de impeg2d_mc.c existe una posible escritura fuera de los límites debido a la falta de verificación de los límites. Esto podría provocar la ejecución remota de código arbitrario sin necesidad de privilegios de ejecución adicionales. Se necesita la interacción del usuario para su explotación.

En varias funciones de DescramblerImpl.cpp, existe un posible use after free debido a un bloqueo inadecuado. Esto podría provocar una escalada local de privilegios sin necesidad de permisos de ejecución adicionales. No se necesita la interacción del usuario para la explotación.

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: riscv: Evitar un recuento de referencia incorrecto en los nodos de CPU Al rellenar las hojas de caché, anteriormente obteníamos el nodo del dispositivo de CPU al principio. Pero cuando ACPI está habilitado, pasamos por una rama específica que regresa temprano y no llama a 'of_node_put' para el nodo que se adquirió. Dado que de todos modos no estamos usando un nodo de dispositivo de CPU para el código ACPI, simplemente podemos mover la inicialización del mismo justo después del bloque ACPI, y tenemos la garantía de tener una llamada 'of_node_put' para el nodo adquirido. Esto evita un recuento de referencia incorrecto del nodo del dispositivo de CPU. Además, la función anterior no verificaba si había errores al adquirir el nodo del dispositivo, por lo que se agregó un retorno -ENOENT para ese caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: gts-helper: corrige fugas de memoria para la ruta de error de iio_gts_build_avail_scale_table() Si per_time_scales[i] o per_time_gains[i] kcalloc falla en el bucle for de iio_gts_build_avail_scale_table(), err_free_out no podrá llamar a kfree() cada vez que i se reduzca a 0, por lo que no se liberarán todos los per_time_scales[0] y per_time_gains[0], lo que provocará fugas de memoria. Arréglelo comprobando si i >= 0.

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: 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/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.