Vulnerabilidades

Se encontró una vulnerabilidad en SourceCodester Best Church Management Software 1.1. Se la ha calificado como crítica. Este problema afecta a algunos procesos desconocidos del archivo /admin/app/profile_crud.php. La manipulación conduce a una inyección SQL. El ataque puede iniciarse de forma remota. La vulnerabilidad se ha divulgado al público y puede utilizarse. Es posible que se vean afectados varios parámetros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86: dell-uart-backlight: corregir la condición de ejecución de serdev La función dell_uart_bl_serdev_probe() llama a devm_serdev_device_open() antes de configurar las operaciones del cliente a través de serdev_device_set_client_ops(). Este orden puede desencadenar una desreferencia de puntero NULL en el controlador de recepción de serdev, ya que asume que serdev->ops es válido cuando SERPORT_ACTIVE está configurado. Esto es similar al problema corregido en el commit 5e700b384ec1 ("platform/chrome: cros_ec_uart: corregir correctamente la condición de ejecución") donde se llamó a devm_serdev_device_open() antes de inicializar por completo el dispositivo. Corrija la ejecución asegurándose de que las operaciones del cliente estén configuradas antes de habilitar el puerto a través de devm_serdev_device_open(). Tenga en cuenta que las llamadas serdev_device_set_baudrate() y serdev_device_set_flow_control() deben realizarse después de la llamada devm_serdev_device_open().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: borrar el estado PTE/PMD de uffd-wp en mremap() Al borrar con mremap() una región de memoria registrada previamente con userfaultfd como protegida contra escritura pero sin UFFD_FEATURE_EVENT_REMAP, una inconsistencia en la depuración de indicadores provoca una falta de coincidencia entre los indicadores vma (que tienen uffd-wp borrado) y los indicadores pte/pmd (que no tienen uffd-wp borrado). Esta falta de coincidencia hace que un mprotect(PROT_WRITE) posterior active una advertencia en page_table_check_pte_flags() debido a la configuración de pte como escribible mientras uffd-wp aún está configurado. Solucione esto borrando siempre explícitamente los indicadores pte/pmd de uffd-wp en cualquier mremap() de este tipo para que los valores sean coherentes con la depuración existente de VM_UFFD_WP. Tenga cuidado de borrar el indicador lógico independientemente de su forma física: un bit PTE, un bit PTE de intercambio o un marcador PTE. Cubra las rutas PTE, PMD enormes y TLB enormes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "usb: gadget: u_serial: Deshabilitar ep antes de configurar el puerto como nulo para corregir el bloqueo causado por el puerto como nulo". Esto revierte el commit 13014969cbf07f18d62ceea40bd8ca8ec9d36cec. Se informa que causa bloqueos en los sistemas Tegra, por lo que se recomienda revertirla por ahora.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc: fix softlockup in __read_vmcore (parte 2) Desde el commit 5cbcb62dddf5 ("fs/proc: fix softlockup in __read_vmcore"), la cantidad de softlockups en __read_vmcore en el momento de kdump ha disminuido, pero aún ocurren a veces. En un entorno con restricciones de memoria como la imagen kdump, un softlockup no es solo un mensaje inofensivo, sino que puede interferir con cosas como la liberación de memoria por parte de RCU, lo que hace que el crashdump se quede atascado. El segundo bucle en __read_vmcore tiene muchas más oportunidades para puntos de suspensión naturales, como programar la salida mientras se espera que se escriban datos, pero aparentemente eso no siempre es suficiente. Agregue un cond_resched() al segundo bucle en __read_vmcore para (con suerte) deshacerse de los softlockups.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Asegúrese de que el puntero de trabajo esté configurado en NULL después de la finalización del trabajo. Después de que se complete un trabajo, el puntero correspondiente en el dispositivo debe configurarse en NULL. Si no se hace esto, se activa una advertencia al descargar el controlador, ya que parece que el trabajo aún está activo. Para evitar esto, asigne el puntero de trabajo a NULL después de completar el trabajo, lo que indica que el trabajo ha finalizado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "libfs: fix infinite directory reads for offset dir" El asignador de desplazamiento de directorio actual (basado en mtree_alloc_cyclic) almacena el siguiente valor de desplazamiento a devolver en octx->next_offset. Este mecanismo normalmente devuelve valores que aumentan monótonamente con el tiempo. Sin embargo, con el tiempo, el valor de desplazamiento recientemente asignado vuelve a un número bajo (por ejemplo, 2) que es menor que otros valores de desplazamiento ya asignados. Yu Kuai informa que, después del commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir"), si el asignador de desplazamiento de un directorio se cierra, las entradas existentes ya no son visibles a través de readdir/getdents porque offset_readdir() deja de enumerar las entradas una vez que el desplazamiento de una entrada es mayor que octx->next_offset. Estas entradas desaparecen de forma persistente: se pueden buscar, pero nunca volverán a aparecer en la salida de readdir(3). La razón para esto es que la confirmación trata los desplazamientos de directorio como valores enteros que aumentan monótonamente en lugar de cookies opacas, e introduce esta comparación: if (dentry2offset(dentry) >= last_index) { En plataformas de 64 bits, el límite superior del valor del desplazamiento de directorio es 2^63 - 1. Los desplazamientos de directorio aumentarán monótonamente durante millones de años sin envolverse. Sin embargo, en plataformas de 32 bits, LONG_MAX es 2^31 - 1. El asignador puede envolverse después de solo unas pocas semanas (en el peor de los casos). Revertir el commit 64a7ce76fb90 ("libfs: arreglar lecturas de directorio infinitas para el desplazamiento dir") para prepararse para una solución que pueda funcionar correctamente en sistemas de 32 bits y podría aplicarse a núcleos LTS recientes donde shmem emplea el mecanismo simple_offset.

Un CWE-259 "Uso de contraseña codificada" para la cuenta raíz en Q-Free MaxTime menor o igual a la versión 2.11.0 permite a un atacante remoto no autenticado ejecutar código arbitrario con privilegios de superusuario a través de SSH.

Una "Discrepancia de respuesta observable" CWE-204 en la página de inicio de sesión en Q-Free MaxTime menor o igual a la versión 2.11.0 permite a un atacante remoto no autenticado enumerar nombres de usuario válidos a través de solicitudes HTTP manipulado.

Un error de validación de origen CWE-346 "Origin Validation Error" en la configuración CORS en Q-Free MaxTime menor o igual a la versión 2.11.0 permite que un atacante remoto no autenticado afecte la confidencialidad, integridad o disponibilidad del dispositivo a través de URL manipulado o solicitudes HTTP.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hrtimers: Controlar el estado de la CPU correctamente en hotplug Considere un escenario donde una CPU pasa de CPUHP_ONLINE a la mitad de un hotunplug de CPU hasta CPUHP_HRTIMERS_PREPARE, y luego vuelve a CPUHP_ONLINE: Dado que hrtimers_prepare_cpu() no se ejecuta, cpu_base.hres_active permanece establecido en 1 durante todo el proceso. Sin embargo, durante una operación de desconexión de la CPU, el tick y los clockevents se apagan en CPUHP_AP_TICK_DYING. Al volver al estado en línea, por ejemplo, CFS supone incorrectamente que el hrtick ya está activo, y la posibilidad de que el dispositivo clockevent pase al modo one-shot también se pierde para siempre para la CPU, a menos que vuelva a un estado inferior a CPUHP_HRTIMERS_PREPARE una vez. Este viaje de ida y vuelta revela otro problema; cpu_base.online no se establece en 1 después de la transición, lo que aparece como WARN_ON_ONCE en enqueue_hrtimer(). Aparte de eso, la mayor parte del estado por CPU tampoco se restablece, lo que significa que hay punteros inactivos en el peor de los casos. Resuelva esto agregando una devolución de llamada startup() correspondiente, que restablece el estado obsoleto por CPU y establece el indicador en línea. [ tglx: haga que la nueva devolución de llamada esté disponible incondicionalmente, elimine la modificación en línea en la devolución de llamada prepare() y borre el estado restante en la devolución de llamada de inicio en lugar de la devolución de llamada de preparación ]

HCL Connections Docs es vulnerable a una divulgación de información confidencial que podría permitir que un usuario obtenga información confidencial a la que no tiene derecho, debido a una gestión inadecuada de los datos solicitados.