Vulnerabilidades

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.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: soluciona el punto muerto con fiemap y bloqueo de extensión Mientras trabajaba en el conjunto de parches para eliminar el bloqueo de extensión, obtuve un lockdep splat con fiemap y pagefaulting con mi nuevo bloqueo de reemplazo de bloqueo de extensión. Este punto muerto existe con nuestro código normal, simplemente no tenemos anotaciones de bloqueo con el bloqueo de extensión, por lo que nunca lo hemos notado. Dado que copiamos la extensión del mapa de archivos al espacio del usuario en cada iteración, tenemos la posibilidad de que se produzcan errores de página. Debido a que mantenemos el bloqueo de extensión para todo el rango, podemos escribir en un rango en el archivo que hemos asignado. Esto se bloquearía con el siguiente seguimiento de pila [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [< 0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [< 0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extend_fiemap+0x7f8/0xad0 [< 0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Escribí un fstest para reproducir este interbloqueo sin mi bloqueo de reemplazo y verifiqué que existe un punto muerto con nuestro bloqueo existente. Para solucionar este problema, simplemente no utilice el bloqueo de extensión durante toda la duración del mapa de archivos. En general, esto es seguro porque realizamos un seguimiento de dónde estamos cuando buscamos en el árbol, por lo que si una extensión ordenada se actualiza en medio de nuestra llamada a fiemap, seguiremos emitiendo las extensiones correctas porque sabemos en qué desplazamiento estábamos. antes. El único lugar donde mantenemos el bloqueo es buscando en delalloc. Dado que las cosas de delalloc pueden cambiar durante la reescritura, queremos bloquear el rango de extensión para tener una vista consistente de delalloc en el momento en que verificamos si necesitamos configurar el indicador delalloc. Con este parche aplicado ya no nos estancamos con mi caso de prueba.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/nouveau: corrige el mutex bloqueado obsoleto en nouveau_gem_ioctl_pushbuf. Si VM_BIND está habilitado en el cliente, el ioctl de envío heredado no se puede usar; sin embargo, si un cliente intenta hacerlo independientemente, lo hará. devolver un error. En este caso, el mutex del cliente permaneció desbloqueado, lo que provocó un punto muerto dentro de nouveau_drm_postclose o cualquier otra llamada nouveau ioctl.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/md-bitmap: corrige el uso incorrecto de sb_index Commit d7038f951828 ("md-bitmap: no usar ->índice para páginas que respaldan el archivo de mapa de bits") página eliminada-> índice del código de mapa de bits, pero dejó una lógica de código incorrecta para clustered-md. El código actual nunca establece el desplazamiento de ranura para los nodos del clúster, a veces causa fallos en el entorno del clúster. Rastreo de llamadas (parcialmente): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_submit_bio+0x8 0/0xf8 [md_mod] __submit_bio+0x178/ 0x300 enviar_bio_noacct_nocheck+0x11c/0x338 enviar_bio_noacct+0x134/0x614 enviar_bio+0x28/0xdc enviar_bh_wbc+0x130/0x1cc enviar_bh+0x1c/0x28

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: Corrige la verificación de límites para dcn35 DcfClocks [Por qué] NumFclkLevelsEnabled se usa para la verificación de límites de DcfClocks en lugar del designado NumDcfClkLevelsEnabled. Eso puede provocar un acceso fuera de los límites al índice de matriz. [Cómo] Utilice la variable designada para comprobar los límites de dcn35 DcfClocks.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: deja de analizar bits de canales cuando se encuentran todos los canales. Si un dispositivo de audio USB establece más bits que la cantidad de canales, podría escribir fuera de la matriz del mapa.