Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: eliminar la comprobación de referencia de Fw incorrecta al ensuciar páginas. Al realizar lecturas de E/S directas, también intentará marcar las páginas como sucias, pero para la ruta de lectura no mantendrá las capacidades de Fw y en ningún caso obtendrá la referencia de Fw.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: sisfb: Fix strbuf array overflow Los valores de las variables xres e yres se colocan en strbuf. Estas variables se obtienen de strbuf1. La matriz strbuf1 contiene caracteres numéricos y un espacio si la matriz contiene caracteres que no son dígitos. Luego, al ejecutar sprintf(strbuf, "%ux%ux8", xres, yres); se escribirán más de 16 bytes en strbuf. Se sugiere aumentar el tamaño de la matriz strbuf a 24. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: secretmem: deshabilitar memfd_secret() si arch no puede establecer el mapa directo Devolver -ENOSYS de la llamada al sistema memfd_secret() si !can_set_direct_map(). Este es el caso, por ejemplo, de algunas configuraciones arm64, donde marcar 4k PTE en el mapa directo como no presentes solo se puede hacer si el mapa directo se configura con una granularidad de 4k en primer lugar (ya que la semántica break-before-make de ARM no permite dividir fácilmente páginas grandes/gigantescas). Más precisamente, en sistemas arm64 con !can_set_direct_map(), set_direct_map_invalid_noflush() es una operación sin efecto, sin embargo, devuelve éxito (0) en lugar de un error. Esto significa que memfd_secret aparentemente "funcionará" (por ejemplo, la llamada al sistema tiene éxito, puede mmap el fd y el error en las páginas), pero en realidad no logra su objetivo de eliminar su memoria del mapa directo. Tenga en cuenta que con este parche, memfd_secret() comenzará a generar errores en sistemas donde can_set_direct_map() devuelve falso (arm64 con CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n y CONFIG_KFENCE=n), pero eso parece mejor que el error silencioso actual. Dado que CONFIG_RODATA_FULL_DEFAULT_ENABLED tiene como valor predeterminado 'y', la mayoría de los sistemas arm64 tienen en realidad un memfd_secret() en funcionamiento y no se ven afectados. Al revisar las iteraciones de la serie de parches memfd_secret originales, parece que deshabilitar la llamada al sistema en estos escenarios era el comportamiento previsto [1] (preferible a que set_direct_map_invalid_noflush devuelva un error ya que eso generaría SIGBUS en el momento de la falla de la página); sin embargo, la verificación se abandonó entre v16 [2] y v17 [3], cuando secretmem se alejó de las asignaciones de CMA. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: garantizar la finalización del manejo de DA_ID antes de eliminar una instancia de NPIV Eliminar una instancia de NPIV requiere que se liberen todos los ndlps de fabric antes de que se puedan eliminar los recursos de un NPIV. Si no se liberan los ndlps de fabric de antemano, se abren condiciones de ejecución por desequilibrio de kref. Se soluciona forzando a que DA_ID se complete de manera sincrónica con el uso de wait_queue.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_pmem: comprobar el estado del dispositivo antes de solicitar la descarga. Si un dispositivo pmem está en mal estado, el lado del controlador podría esperar el commit del host para siempre en virtio_pmem_flush(), lo que provocaría que el sistema se cuelgue. Por lo tanto, agregue una comprobación de estado al comienzo de virtio_pmem_flush() para que vuelva antes si el dispositivo no está activado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: maneja de manera consistente la corrupción de DSS. La implementación de pares con errores puede enviar opciones de DSS corruptas, lo que genera varias advertencias de manera constante en la ruta de datos. Use afirmaciones DEBUG_NET para evitar el splat en algunas compilaciones y manejar el error de manera consistente, volcando los MIB relacionados y realizando una copia de seguridad o un restablecimiento según el tipo de subflujo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: borrar explícitamente el puntero sk, cuando pf->create falla Recientemente hemos notado exactamente el mismo splat de KASAN que en el commit 6cd4a78d962b ("net: no deje un puntero sk colgando, cuando falla la creación del socket"). El problema es que el commit no solucionó completamente el problema, ya que algunas implementaciones de pf->create no usan sk_common_release en sus rutas de error. Por ejemplo, podemos usar el mismo reproductor que en el commit anterior, pero cambiando ping a arping. arping usa el socket AF_PACKET y si packet_create falla, solo sk_free el objeto sk asignado. Si bien podríamos perseguir todas las implementaciones de pf->create y asegurarnos de que anulen el objeto sk liberado en caso de error del socket, no podemos garantizar que los protocolos futuros no cometan el mismo error. Por lo tanto, es más fácil simplemente convertir explícitamente en NULL el puntero sk al regresar de pf->create en __sock_create. Sabemos que pf->create siempre libera el objeto sk asignado en caso de error, por lo que si el puntero no es NULL, definitivamente está colgado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: Detener el monitor de rendimiento activo antes de ser destruido Al cerrar el descriptor de archivo, el monitor de rendimiento activo no se detiene. Aunque todos los monitores de rendimiento se destruyen en `vc4_perfmon_close_file()`, el puntero del monitor de rendimiento activo (`vc4->active_perfmon`) aún se conserva. Si abrimos un nuevo descriptor de archivo y enviamos algunos trabajos con monitores de rendimiento, el controlador intentará detener el monitor de rendimiento activo utilizando el puntero obsoleto en `vc4->active_perfmon`. Sin embargo, este puntero ya no es válido porque el proceso anterior ya ha finalizado y todos los monitores de rendimiento asociados con él han sido destruidos y liberados. Para solucionar esto, cuando el monitor de rendimiento activo pertenece a un proceso determinado, deténgalo explícitamente antes de destruirlo y liberarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: dp83869: se corrige la corrupción de memoria al habilitar la fibra Al configurar el puerto de fibra, el controlador PHY DP83869 llama incorrectamente a linkmode_set_bit() con una máscara de bits (1 << 10) en lugar de un número de bit (10). Esto corrompe alguna otra ubicación de memoria; en el caso de arm64, el puntero priv en la misma estructura. Dado que los indicadores de publicidad se actualizan desde supported al final de la función, la línea incorrecta no es necesaria en absoluto y se puede eliminar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: amd_sfh: Cambiar a la versión administrada por el dispositivo dmam_alloc_coherent() El uso de la versión administrada por el dispositivo permite simplificar la limpieza en la ruta de error de probe(). Además, esta versión administrada por el dispositivo garantiza una desinfección adecuada, lo que ayuda a resolver errores de memoria, fallas de página, btrfs que pasa a ser de solo lectura y corrupción de disco de btrfs.

Se ha encontrado una vulnerabilidad clasificada como crítica en Codezips Online Institute Management System 1.0. Se trata de una función desconocida del archivo /manage_website.php. La manipulación del argumento website_image permite la carga sin restricciones. Es posible lanzar el ataque de forma remota. El exploit ha sido divulgado al público y puede ser utilizado.

Se ha encontrado una vulnerabilidad en Codezips Online Institute Management System 1.0 y se ha clasificado como crítica. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /edit_user.php. La manipulación del argumento image permite la carga sin restricciones. El ataque se puede ejecutar de forma remota. El exploit se ha hecho público y puede utilizarse.