Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: corrige una posible double free en fs_any_create_groups Cuando kcalloc() para ft->g tiene éxito pero kvzalloc() para in falla, fs_any_create_groups() liberará ft-> gramo. Sin embargo, su llamador fs_any_create_table() liberará ft->g nuevamente llamando a mlx5e_destroy_flow_table(), lo que conducirá a un double free. Solucione este problema configurando ft->g en NULL en fs_any_create_groups().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs:zoned: corrige el orden de bloqueo en btrfs_zone_activate() El CI de btrfs informó una advertencia de bloqueo de la siguiente manera al ejecutar generic generic/129. ADVERTENCIA: se detectó posible dependencia de bloqueo circular 6.7.0-rc5+ #1 No contaminado ---------------------------------- -------------------- kworker/u5:5/793427 está intentando adquirir el bloqueo: ffff88813256d028 (&cache->lock){+.+.}-{2: 2}, en: btrfs_zone_finish_one_bg+0x5e/0x130 pero la tarea ya mantiene el bloqueo: ffff88810a23a318 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}, en: btrfs_zone_finish_one_bg+0x34/0x130 cuyo bloqueo ya depende del cerradura nueva. la cadena de dependencia existente (en orden inverso) es: -> #1 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}: ... -> #0 (&cache->lock){+. +.}-{2:2}: ... Esto se debe a que tomamos fs_info->zone_active_bgs_lock después del bloqueo de un block_group en btrfs_zone_activate() mientras hacemos lo contrario en otros lugares. Solucione el problema expandiendo la sección crítica de fs_info->zone_active_bgs_lock y llevándola antes del bloqueo de block_group.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: s390/aes - Corrige la sobrelectura del buffer en modo CTR Al procesar el último bloque, el código ctr s390 siempre leerá un bloque completo, incluso si no hay un bloque completo de datos restantes. Solucione este problema utilizando la longitud real restante y cópielo primero en un búfer para procesarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: rgb: corrige la falta de clk_put() en las rutas de manejo de errores de tegra_dc_rgb_probe(). Si clk_get_sys(..., "pll_d2_out0") falla, la llamada clk_get_sys() debe deshacerse. Agregue el clk_put que falta y una nueva etiqueta 'put_pll_d_out0' en la ruta de manejo de errores y úsela.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: soluciona un memleak en vmw_gmrid_man_get_node Cuando falla ida_alloc_max, se deben liberar los recursos asignados anteriormente, incluido *res asignado por kmalloc y ttm_resource_init.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: SOF: amd: corrige la pérdida de memoria en amd_sof_acp_probe() El controlador usa kasprintf() para inicializar los miembros fw_{code,data}_bin de la estructura acp_dev_data, pero kfree() nunca se llama para desasignar la memoria, lo que resulta en una pérdida de memoria. Solucione el problema cambiando a devm_kasprintf(). Además, asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: atlantic: elimina double free en la lógica de manejo de errores El controlador tiene una fuga lógica en la asignación de datos del anillo/free, donde se podría llamar a aq_ring_free varias veces en el mismo anillo, si el sistema está bajo estrés y obtuve un error de asignación de memoria. Se utilizó un puntero de anillo como indicador de error, pero esto no es correcto ya que solo se asignan/desasignan datos de anillo. El anillo en sí es un miembro de la matriz. Cambiar las funciones de asignación de anillos para devolver el código de error directamente. Esto simplifica el manejo de errores y elimina aq_ring_free en la capa superior.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: debugfs: corrige el manejo de espera/cancelación durante la eliminación Ben Greear informa además bloqueos durante la eliminación de debugfs concurrentes mientras se accede a los archivos, aunque el código en cuestión ahora usa cancelaciones de debugfs. Resulta que a pesar de toda la revisión sobre el bloqueo, no entendimos por completo que la lógica es incorrecta: si el recuento llega a cero, podemos finalizar (y no necesitamos esperar a que se complete), pero si no es así, tenemos que activar todos los cancelaciones. Tal como está escrito, _nunca_ podemos entrar en el ciclo que desencadena las cancelaciones. Arregla esto y explícalo mejor mientras lo haces.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-raid: sync_thread realmente congelado durante la suspensión 1) commit f52f5c71f3d4 ("md: fix deteniendo el hilo de sincronización") elimina MD_RECOVERY_FROZEN de __md_stop_writes() y no se da cuenta de que dm-raid se basa en __md_stop_writes() para congelar sync_thread indirectamente. Solucione este problema agregando MD_RECOVERY_FROZEN en md_stop_writes(), y dado que stop_sync_thread() solo se usa para dm-raid en este caso, mueva también stop_sync_thread() a md_stop_writes(). 2) La bandera MD_RECOVERY_FROZEN no significa que el subproceso de sincronización esté congelado, solo impide que se inicie un nuevo subproceso de sincronización y no puede detener el subproceso de sincronización en ejecución; Para congelar sync_thread, después de configurar la bandera, se debe usar stop_sync_thread(). 3) La bandera MD_RECOVERY_FROZEN no significa que se detengan las escrituras; usarla como condición para md_stop_writes() en raid_postsuspend() no parece correcta. Considere que el reentrante stop_sync_thread() no hace nada, siempre llame a md_stop_writes() en raid_postsuspend(). 4) raid_message puede establecer/borrar el indicador MD_RECOVERY_FROZEN en cualquier momento, y si MD_RECOVERY_FROZEN se borra mientras la matriz está suspendida, un nuevo sync_thread puede iniciarse inesperadamente. Solucione este problema al no permitir que raid_message() cambie el estado de sync_thread durante la suspensión. Tenga en cuenta que después de confirmar f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), la prueba shell/lvconvert-raid-reshape.sh comienza a bloquearse en stop_sync_thread(), y con las correcciones anteriores, la prueba ya no se bloqueará allí, sin embargo , la prueba seguirá fallondo y se quejará de que ext4 está dañado. Y con este parche, la prueba no se bloqueará debido a stop_sync_thread() ni fallará debido a que ext4 ya está dañado. Sin embargo, todavía hay un punto muerto relacionado con dm-raid456 que se solucionará en los siguientes parches.

Se encontró una vulnerabilidad en SourceCodester Online Birth Certificate Management System 1.0. Ha sido declarada problemática. Esta vulnerabilidad afecta a código desconocido del archivo /admin. La manipulación conduce a archivos o directorios accesibles. El ataque se puede iniciar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. VDB-264742 es el identificador asignado a esta vulnerabilidad.

Se encontró una vulnerabilidad en SourceCodester Online Examination System 1.0. Ha sido calificada como crítica. Este problema afecta un procesamiento desconocido del archivo Registeracc.php. La manipulación del argumento email conduce a la inyección de SQL. El ataque puede iniciarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador asociado de esta vulnerabilidad es VDB-264743.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: crypto: rk3288 - Arreglar el uso después de liberar en unprepare La llamada de unprepare debe realizarse antes de la llamada de finalización ya que esta última puede liberar la solicitud.