Vulnerabilidades

Las versiones 19.4, 18.5.3 y anteriores de InCopy se ven afectadas por una vulnerabilidad de carga sin restricciones de archivos de tipo peligroso que podría provocar la ejecución de código arbitrario por parte de un atacante. Un atacante podría aprovechar esta vulnerabilidad cargando un archivo malicioso que luego se puede ejecutar en el servidor. Para aprovechar este problema se requiere la interacción del usuario.

Las versiones 19.4, 18.5.3 y anteriores de InDesign Desktop se ven afectadas por una vulnerabilidad de carga sin restricciones de archivos con tipos peligrosos que podría provocar la ejecución de código arbitrario. Un atacante podría aprovechar esta vulnerabilidad cargando un archivo malicioso que, al ejecutarse, podría ejecutar código arbitrario en el contexto del servidor. Para aprovechar este problema se requiere la interacción del usuario.

Las versiones 2020.6, 2022.4 y anteriores de Adobe Framemaker se ven afectadas por una vulnerabilidad de lectura fuera de los límites al analizar un archivo manipulado, lo que podría provocar una lectura más allá del final de una estructura de memoria asignada. Un atacante podría aprovechar esta vulnerabilidad para ejecutar código en el contexto del usuario actual. Para explotar este problema es necesaria la interacción del usuario, ya que la víctima debe abrir un archivo malicioso.

Las versiones 3.0.3 y anteriores de Substance3D - Stager se ven afectadas por una vulnerabilidad de escritura fuera de los límites que podría provocar la ejecución de código arbitrario en el contexto del usuario actual. Para explotar este problema es necesaria la interacción del usuario, ya que la víctima debe abrir un archivo malicioso.

PHPGurukul Hospital Management System 4.0 es vulnerable a Cross Site Scripting (XSS) a través de los parámetros patname, pataddress y medhis en doctor/add-patient.php y doctor/edit-patient.php.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Deshabilitar el tiempo de espera de DMCUB para DCN35 [Por qué] DMCUB puede tardar intermitentemente más de lo esperado en procesar comandos. La antigua política de ASIC era continuar mientras se registra un error de diagnóstico, lo que funciona bien para ASIC sin IPS, pero con IPS esto podría llevar a una condición de ejecución donde intentamos acceder al estado de DCN mientras es inaccesible, lo que lleva a un bloqueo del sistema cuando el puerto NIU no está deshabilitado o los accesos de registro agotan ese tiempo de espera y la configuración de pantalla en un estado indefinido. [Cómo] Necesitamos investigar por qué estos accesos tardan más de lo esperado, pero por ahora debemos deshabilitar el tiempo de espera en DCN35 para evitar esta condición de ejecución. Dado que las esperas ocurren solo en niveles de interrupción más bajos, el riesgo de tomar demasiado tiempo en IRQ más alto y causar un tiempo de espera del perro guardián del sistema es mínimo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: stm32/cryp - call finalize with bh disabled La operación finalize en modo de interrupción produce una advertencia de recursión de spinlock. La razón es que BH debe estar deshabilitado durante este proceso.

Vulnerabilidad de neutralización incorrecta de elementos especiales utilizados en un comando SQL ('Inyección SQL') y validación de entrada incorrecta en TRtek Software Distant Education Platform permite inyección SQL e inyección de parámetros. Este problema afecta a la plataforma de educación a distancia: antes de 3.2024.11.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrija el valor definido para AMDGPU_DMUB_NOTIFICATION_MAX [Por qué y cómo] En realidad, expone '6' tipos en la enumeración dmub_notification_type. No 5. El uso de un número menor para crear la matriz dmub_callback y dmub_thread_offload tiene el potencial de acceder a un elemento fuera del límite de la matriz. Arréglelo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smack: tcp: ipv4, corregir etiquetado incorrecto Actualmente, Smack refleja la etiqueta de las conexiones entrantes tcp/ipv4: cuando una etiqueta 'foo' se conecta a una etiqueta 'bar' con tcp/ipv4, 'foo' siempre obtiene 'foo' en los paquetes ipv4 devueltos. Por lo tanto, 1) los paquetes devueltos están etiquetados incorrectamente ('foo' en lugar de 'bar') 2) 'bar' puede escribir en 'foo' sin estar autorizado para escribir. Aquí hay un escenario para ver esto: * Tome dos máquinas, llamémoslas C y S, con Smack activo en el estado predeterminado (sin configuraciones, sin reglas, sin hosts etiquetados, solo etiquetas incorporadas) * En S, agregue la regla de Smack 'foo bar w' (las etiquetas 'foo' y 'bar' están instanciadas en S en este momento) * En S, en la etiqueta 'bar', inicie un programa que escuche conexiones entrantes tcp/ipv4 * Desde C, en la etiqueta 'foo', conéctese al oyente en S. (la etiqueta 'foo' está instanciada en C en este momento) La conexión es exitosa y funciona. * Envíe algunos datos en ambas direcciones. * Recolecte tráfico de red de esta conexión. Todos los paquetes en ambas direcciones están etiquetados con el CIPSO de la etiqueta 'foo'. Por lo tanto, la etiqueta 'bar' escribe en 'foo' sin estar autorizada, e incluso sin ser conocida en C. Si a alguien le importa: exactamente lo mismo sucede con DCCP. Este comportamiento se manifestó por primera vez en la versión 2.6.29.4 (ver Correcciones a continuación) y parece no ser intencional. Al menos, no se proporcionó ninguna explicación. Cambié la etiqueta de los paquetes devueltos por "barra" para que coincida con lo que afirma la documentación de Smack.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fsnotify: borrar indicadores PARENT_WATCHED de forma diferida En algunas configuraciones, los directorios pueden tener muchas entradas (normalmente negativas). Por lo tanto, la función __fsnotify_update_child_dentry_flags() puede tardar una cantidad significativa de tiempo. Dado que la mayor parte de esta función se realiza en inode->i_lock, esto provoca una contención significativa en el bloqueo cuando eliminamos la vigilancia del directorio, ya que la llamada __fsnotify_update_child_dentry_flags() desde fsnotify_recalc_mask() compite con las llamadas __fsnotify_update_child_dentry_flags() desde __fsnotify_parent() que ocurren en los hijos. Esto puede provocar informes de bloqueo suave informados por los usuarios. Solucione el problema llamando a fsnotify_update_children_dentry_flags() para establecer los indicadores PARENT_WATCHED solo cuando el padre comience a vigilar a los hijos. Cuando el padre deja de vigilar a los hijos, borra los indicadores de falsos positivos PARENT_WATCHED de forma diferida en __fsnotify_parent() para cada hijo al que acceda.

Las versiones 3.0.3 y anteriores de Substance3D - Stager se ven afectadas por una vulnerabilidad de escritura fuera de los límites que podría provocar la ejecución de código arbitrario en el contexto del usuario actual. Para explotar este problema es necesaria la interacción del usuario, ya que la víctima debe abrir un archivo malicioso.