Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: no configure el indicador MFP para GTK El firmware no necesita el indicador MFP para GTK, incluso puede provocar que el firmware falle. en caso de que el AP esté configurado con: cifrado de grupo TKIP y MFPC. Enviaríamos el GTK con cifrado = TKIP y MFP, lo cual, por supuesto, no es posible.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvme: se corrigió el error de reconexión debido a la asignación de etiquetas reservadas. Encontramos un problema en el entorno de producción al usar NVMe sobre RDMA, la reconexión de admin_q falló para siempre mientras el objetivo remoto y la red están bien. Después de investigarlo, descubrimos que puede deberse a un punto muerto de ABBA debido a la asignación de etiquetas. En mi caso, la etiqueta estaba retenida por una solicitud de mantenimiento en espera dentro de admin_q, ya que desactivamos admin_q mientras reiniciamos Ctrl, por lo que la solicitud se realizó como inactiva y no se procesará antes de que el reinicio se realice correctamente. Como fabric_q comparte el conjunto de etiquetas con admin_q, mientras reconectamos el objetivo remoto, necesitamos una etiqueta para el comando de conexión, pero la única etiqueta reservada estaba mantenida por el comando Keep Alive que esperaba dentro de admin_q. Como resultado, no pudimos volver a conectar admin_q para siempre. Para solucionar este problema, creo que deberíamos mantener dos etiquetas reservadas para la cola de administración.