Vulnerabilidades

Existen múltiples vulnerabilidades de Cross Site Scripting (XSS) en PHPGurukul Hospital Management System 4.0 a través del parámetro docname en /admin/add-doctor.php y /admin/edit-doctor.php

Existen múltiples vulnerabilidades de Cross Site Scripting en PHPGurukul Hospital Management System 4.0 a través del parámetro docname en /doctor/edit-profile.php y el parámetro adminremark en /admin/query-details.php.

Cilium es una solución de redes, observabilidad y seguridad con un plano de datos basado en eBPF. A partir de la versión 1.14.0 y antes de las versiones 1.14.16 y 1.15.10, una regla de política que deniegue un prefijo más amplio que `/32` puede ignorarse si hay una regla de política que haga referencia a un prefijo más estrecho (`CIDRSet` o `toFQDN`) y esta regla de política más estrecha especifica `enableDefaultDeny: false` o `- toEntities: all`. Tenga en cuenta que una regla que especifique `toEntities: world` o `toEntities: 0.0.0.0/0` no es suficiente, debe ser para la entidad `all`. Este problema se ha corregido en Cilium v1.14.16 y v1.15.10. Como este problema solo afecta a las políticas que utilizan `enableDefaultDeny: false` o que establecen `toEntities` en `all`, hay algunas soluciones alternativas disponibles. Para los usuarios con políticas que utilizan `enableDefaultDeny: false`, elimine esta opción de configuración y defina explícitamente las reglas de permiso requeridas. Para los usuarios con políticas de salida que especifican explícitamente `toEntities: all`, utilice `toEntities: world`.

CodeAstro Membership Management System v1.0 es vulnerable a Cross Site Scripting (XSS) a través del parámetro de dirección en add_members.php y edit_member.php.

CodeAstro Membership Management System v1.0 es vulnerable a Cross Site Scripting (XSS) a través del parámetro membershipType en edit_type.php

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se ha corregido la desreferenciación NULL en mlx5e_tir_builder_alloc(). En mlx5e_tir_builder_alloc(), kvzalloc() puede devolver NULL, que se desreferencia en la siguiente línea en una referencia al campo de modificación. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Corregir ruta de error en transmisión WQE de paquetes múltiples Eliminar la desasignación errónea en caso de que no se haya establecido una asignación DMA El código de transmisión WQE de paquetes múltiples intenta obtener una asignación DMA para el skb. Esto podría fallar, por ejemplo, bajo presión de memoria, cuando el controlador IOMMU simplemente no puede asignar más memoria para las tablas de páginas. Si bien el código intenta manejar esto en la ruta debajo de la etiqueta err_unmap, desasigna erróneamente una entrada de la lista FIFO de asignaciones activas del sq. Dado que el intento de asignación actual falló, esta desasignación está eliminando alguna asignación DMA aleatoria que aún podría ser necesaria. Si la función PCI ahora presenta ese IOVA, el IOMMU puede asumir un acceso DMA no autorizado y, por ejemplo, en s390 pone la función PCI en estado de error. El comportamiento erróneo se observó en un entorno de prueba de estrés que creó presión de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: static_call: Manejar el error de inicialización del módulo correctamente en static_call_del_module() La inserción del módulo invoca static_call_add_module() para inicializar las llamadas estáticas en un módulo. static_call_add_module() invoca __static_call_init(), que asigna una estructura static_call_mod para encapsular los sitios de llamadas estáticas integrados de la clave asociada en ella para que se puedan agregar más módulos o para agregar el módulo a la cadena de módulos. Si esa asignación fallo, la función regresa con un código de error y el núcleo del módulo invoca static_call_del_module() para limpiar las entradas static_call_mod agregadas eventualmente. Esto funciona correctamente, cuando todas las claves utilizadas por el módulo se convirtieron a una cadena de módulos antes del error. Si no, static_call_del_module() causa un #GP ya que asume ciegamente que key::mods apunta a una estructura static_call_mod válida. El problema es que key::mods no es un miembro de estructura individual de struct static_call_key, es parte de una unión para ahorrar espacio: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites es un puntero a la lista de sitios de uso integrados de la llamada estática. El tipo del puntero se diferencia por el bit 0. Un puntero mods tiene el bit claro, el puntero sites tiene el bit establecido. Como static_call_del_module() asume ciegamente que el puntero es un tipo static_call_mod válido, no puede verificar este caso de fallo y desreferencia el puntero a la lista de sitios de llamada integrados, lo que obviamente es falso. Solucione esto verificando si la clave tiene un puntero sites o mods. Si es un puntero sites, entonces no se debe tocar la clave. Como los sitios se recorren en el mismo orden que en __static_call_init(), el recorrido del sitio puede terminarse porque el código de inicio no ha tocado todos los sitios posteriores debido a la salida de error. Si se convirtió antes de que fallara la asignación, entonces el bucle interno que busca una coincidencia de módulo no encontrará nada. un fallo en la segunda asignación en __static_call_init() es inofensiva y no requiere un tratamiento especial. La primera asignación tuvo éxito y convirtió la clave en una cadena de módulos. Esa primera entrada tiene mod::mod == NULL y mod::next == NULL, por lo que el bucle interno de static_call_del_module() no encontrará una coincidencia de módulo ni una cadena de módulos. El siguiente sitio en el recorrido ya se convirtió, pero no puede coincidir con el módulo, o saldrá del bucle externo porque tiene un puntero static_call_site y no un puntero static_call_mod.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpftool: corrige comportamiento indefinido en qsort(NULL, 0, ...) Cuando netfilter no tiene ninguna entrada para mostrar, se llama a qsort con qsort(NULL, 0, ...). Esto da como resultado un comportamiento indefinido, como informa UBSan: net.c:827:2: error en tiempo de ejecución: puntero nulo pasado como argumento 1, que se declara que nunca será nulo Aunque el estándar C no indica explícitamente si llamar a qsort con un puntero NULL cuando el tamaño es 0 constituye un comportamiento indefinido, la Sección 7.1.4 del estándar C (Uso de funciones de librería) menciona: "Cada una de las siguientes afirmaciones se aplica a menos que se indique explícitamente lo contrario en las descripciones detalladas que siguen: si un argumento de una función tiene un valor no válido (como un valor fuera del dominio de la función, o un puntero fuera del espacio de direcciones del programa, o un puntero nulo, o un puntero a almacenamiento no modificable cuando el parámetro correspondiente no está calificado como constante) o un tipo (después de la promoción) no esperado por una función con un número variable de argumentos, el comportamiento es indefinido". Para evitar esto, agregue un retorno temprano cuando nf_link_info sea NULL para evitar llamar a qsort con un puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: agregar refcnt a la estructura ksmbd_conn Al enviar una solicitud de interrupción de oplock, se utiliza opinfo->conn, pero freed ->conn se puede utilizar en multicanal. Este parche agrega un recuento de referencia a la estructura ksmbd_conn para que se pueda liberar cuando ya no se utiliza.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/hdcp: Verificar la validez de la estructura GSC En ocasiones, xe_gsc no se inicializa cuando se verifica en la verificación de capacidad HDCP. Agregar verificación de estructura gsc para evitar errores de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige el bloqueo potencial si se llama a qi_submit_sync con un recuento de 0 Si se invoca qi_submit_sync() con 0 descriptores de invalidación (por ejemplo, para fines de vaciado de DMA), podemos encontrarnos con un error en el que un hilo de envío no detecta la finalización de invalidation_wait. Posteriormente, esto condujo a un bloqueo suave. Actualmente, este error no tiene impacto en los usuarios existentes porque ningún llamante está enviando invalidaciones con 0 descriptores. Esta corrección permitirá a los futuros usuarios (como DMA drain) llamar a qi_submit_sync() con un recuento de 0. Supongamos que el hilo T1 invoca qi_submit_sync() con descriptores distintos de cero, mientras que, al mismo tiempo, el hilo T2 llama a qi_submit_sync() con cero descriptores. Ambos hilos entran entonces en un bucle while, esperando a que se completen sus respectivos descriptores. T1 detecta su finalización (es decir, el estado invalidation_wait de T1 cambia a QI_DONE por HW) y procede a llamar a reclaim_free_desc() para recuperar todos los descriptores, incluyendo potencialmente los adyacentes de otros subprocesos que también están marcados como QI_DONE. Durante este tiempo, mientras T2 espera adquirir el qi->q_lock, el hardware IOMMU puede completar la invalidación para T2, estableciendo su estado en QI_DONE. Sin embargo, si la ejecución de reclaim_free_desc() por parte de T1 libera el descriptor invalidation_wait de T2 y cambia su estado a QI_FREE, T2 no observará el estado QI_DONE para su invalidation_wait y permanecerá bloqueado indefinidamente. Este bloqueo suave no ocurre cuando solo se envían descriptores distintos de cero. En tales casos, los descriptores de invalidación se intercalan entre los descriptores de espera con el estado QI_IN_USE, actuando como barreras. Estas barreras evitan que el código de recuperación libere por error descriptores que pertenecen a otros remitentes. Considere la siguiente línea de tiempo de ejemplo: T1 T2 ========================================= ID1 WD1 while(WD1!=QI_DONE) unlock lock WD1=QI_DONE* WD2 while(WD2!=QI_DONE) unlock lock WD1==QI_DONE? ID1=QI_DONE WD2=DONE* reclaim() ID1=FREE WD1=FREE WD2=FREE unlock soft lockup! T2 nunca ve QI_DONE en WD2 Donde: ID = descriptor de invalidación WD = descriptor de espera * Escrito por hardware La raíz del problema es que el indicador de estado del descriptor QI_DONE se usa para dos propósitos conflictivos: 1. señalar que un descriptor está listo para ser recuperado (para ser liberado) 2. señalar por el hardware que un descriptor de espera está completo La solución (en este parche) es la separación de estados mediante el uso del indicador QI_FREE para #1. Una vez que los descriptores de invalidación de un hilo están completos, su estado se establecería en QI_FREE. La función reclaim_free_desc() solo liberaría los descriptores marcados como QI_FREE en lugar de los marcados como QI_DONE. Este cambio asegura que T2 (del ejemplo anterior) observará correctamente la finalización de su invalidation_wait (marcada como QI_DONE).