Vulnerabilidades

En el componente smartLibrary de HRForecast Suite 0.4.3, se descubrió una vulnerabilidad de inyección SQL en el parámetro valueKey. Esta falla permite a cualquier usuario autenticado ejecutar consultas SQL arbitrarias mediante payloads manipulados dirigidas a valueKey en el endpoint api/smartlibrary/v2/en/dictionaries/options/lookup.

n8n es una plataforma de automatización de flujos de trabajo. Desde la versión 1.77.0 hasta la 1.98.2, se identificó una vulnerabilidad de cross site scripting (XSS) almacenado en n8n, específicamente en el elemento HTML del formulario del nodo Form Trigger. Un atacante autenticado puede inyectar HTML malicioso mediante un con un payload srcdoc que incluye la ejecución arbitraria de JavaScript. El atacante también puede inyectar JavaScript malicioso mediante el uso de <video> acoplado a <source> mediante un evento onerror. Al usar un iframe o una combinación de video y etiqueta source, esta vulnerabilidad permite la apropiación de cuentas (ATO) mediante la exfiltración de n8n-browserId y cookies de sesión de usuarios autenticados que visitan un formulario manipulado con fines maliciosos. Con estos tokens y cookies, un atacante puede suplantar la identidad de la víctima y cambiar los detalles de la cuenta, como las direcciones de correo electrónico, lo que le otorga control total sobre la cuenta, especialmente si la autenticación de dos factores (A2F) no está habilitada. Los usuarios deben actualizar a la versión 1.98.2 o superior.

Discourse es una plataforma de discusión de código abierto. El nombre de usuario del banner de bienvenida para usuarios registrados puede ser vulnerable a ataques XSS, que afectan al usuario o a un administrador que se hace pasar por él. Los administradores pueden modificar temporalmente el texto del sitio welcome_banner.header.logged_in_members para eliminar el marcador de posición preferred_display_name o no suplantar a ningún usuario por el momento. Esta vulnerabilidad se corrigió en la versión 3.5.0.beta8.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eventpoll: Arregla recursión semi-ilimitada Garantiza que las instancias de epoll nunca puedan formar un grafo más profundo que los enlaces EP_MAX_NESTS+1. Actualmente, ep_loop_check_proc() garantiza que el grafo no tenga bucles y realiza algunas comprobaciones de profundidad de recursión, pero esas comprobaciones de profundidad de recursión no limitan la profundidad del árbol resultante por dos razones: - No miran hacia arriba en el árbol. - Si hay múltiples rutas descendentes de diferentes longitudes, solo una de las rutas se considera realmente para la comprobación de profundidad desde el commit 28d82dc1c4ed ("epoll: limitar rutas"). Esencialmente, la comprobación de profundidad de recursión actual en ep_loop_check_proc() solo sirve para evitar que recurra demasiado profundamente mientras comprueba bucles. Se realiza una comprobación más exhaustiva en reverse_path_check() después de que ya se haya creado el nuevo borde del grafo; Esto comprueba, entre otras cosas, que no existan rutas ascendentes desde ningún archivo que no sea epoll con una longitud de más de 5 aristas. Sin embargo, esta comprobación no se aplica a los archivos que no son epoll. Como resultado, es posible realizar una recursión a una profundidad de al menos aproximadamente 500, probada en la versión v6.15. (No estoy seguro de si es posible una recursión más profunda; esto puede haber cambiado con el commit 8c44dac8add7 ("eventpoll: Corrección del problema de inversión de prioridad")). Para solucionarlo: 1. En ep_loop_check_proc(), anote la profundidad del subárbol de cada nodo visitado y utilice las profundidades del subárbol para el cálculo de la profundidad total, incluso si ya se ha visitado un subárbol. 2. Añada ep_get_upwards_depth_proc() para determinar de forma similar la profundidad máxima de un recorrido ascendente. 3. En ep_loop_check(), utilice estos valores para limitar la longitud total de la ruta entre nodos epoll a EP_MAX_NESTS aristas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: falla la cancelación de un inodo erróneo tras eliminar el nombre. El reproductor usa un archivo "file0" en un sistema de archivos ntfs3 con un i_link dañado. Al renombrar, el inodo de archivo "file0" se marca como erróneo porque no se puede eliminar el nombre del archivo. El error subyacente radica en que se llama a make_bad_inode() en un inodo activo. En algunos casos, la búsqueda de icache encuentra un inodo normal, se llama a d_splice_alias() para asociarlo a dentry, mientras que otro hilo decide llamar a make_bad_inode() en él; eso lo expulsaría de icache, pero ya lo habíamos encontrado allí anteriormente. En otros casos, es simplemente: "Tenemos un inodo asociado a dentry; así es como lo obtuvimos; llamemos a make_bad_inode() en él, solo por diversión".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vmci: Impedir el envío de payloads no inicializadas El reproductor ejecuta la llamada unlocked_ioctl del host en dos tareas diferentes. Cuando init_context falla, la estructura vmci_event_ctx no se inicializa por completo al ejecutar vmci_datagram_dispatch() para enviar eventos a todos los contextos de la máquina virtual. Esto afecta al datagrama tomado de la cola de datagramas de su contexto por otra tarea, porque el payload del datagrama no se inicializa según el tamaño payload_size, lo que provoca que los datos del kernel se filtren al espacio de usuario. Antes de enviar el datagrama y antes de configurar el contenido del payload, configure explícitamente el contenido de la carga útil a 0 para evitar la fuga de datos causada por la inicialización incompleta del payload.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: fbtft: se corrige una posible fuga de memoria en fbtft_framebuffer_alloc(). En las rutas de error, tras la asignación correcta de la estructura fb_info, la memoria asignada en fb_deferred_io_init() para info->pagerefs no se libera. Para solucionar esto, se añade la función de limpieza en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powercap: dtpm_cpu: Corrección de la desreferencia de puntero nulo en get_pd_power_uw(). La función get_pd_power_uw() puede fallar con una desreferencia de puntero nulo cuando em_cpu_get() devuelve NULL. Esto ocurre cuando una CPU se vuelve inoperativa durante la ejecución, lo que provoca que get_cpu_device() devuelva NULL. Este comportamiento se propaga a través de em_cpu_get() y provoca un fallo cuando em_span_cpus() desreferencia el puntero nulo. Se añade una comprobación de NULL después de em_cpu_get() y se devuelve 0 si no está disponible, coincidiendo con el comportamiento de reserva existente en __dtpm_cpu_setup(). [rjw: Omitir una línea de código vacía sobrante]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM/devfreq: Comprobar el gobernador antes de usar governor->name. El commit 96ffcdf239de ("PM/devfreq: Eliminar el nombre redundante de governor_name de la estructura devfreq") elimina governor_name y usa governor->name para reemplazarlo. Sin embargo, devfreq->governor podría ser NULL y usar directamente devfreq->governor->name podría causar una excepción de puntero nulo. Se debe mover la comprobación del gobernador a antes de usar governor->name.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, ktls: Se corrige la corrupción de datos al usar bpf_msg_pop_data() en ktls. Al enviar datos de texto plano, inicialmente se calculaba la longitud del texto cifrado correspondiente. Sin embargo, si posteriormente se reducía la longitud de los datos de texto plano mediante la política de socket, no se podía recalcular la longitud del texto cifrado. Esto provoca que se transmitan búferes con datos sin inicializar durante la transmisión del texto cifrado. Esto provoca que se añadan bytes sin inicializar después de un paquete completo de "Datos de Aplicación", lo que genera errores en el receptor al analizar el registro TLS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: manejar jset (si a & b ...) como un salto en el cálculo CFG. BPF_JSET es un salto condicional y actualmente verifier.c:can_jump() no lo detecta. Esto puede provocar registros activos y cálculos SCC incorrectos. Por ejemplo, en el siguiente ejemplo: 1: r0 = 1; 2: r2 = 2; 3: si r1 & 0x7 goto +1; 4: salir; 5: r0 = r2; 6: salir; Sin esta corrección, insn_successors(3) solo devolverá (4), se omitiría un salto a (5) y r2 no se marcaría como activo en (3).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: gpib: corrección de la copia de un campo de relleno no asignado al espacio de usuario. La introducción de un campo de relleno en gpib_board_info_ioctl se muestra como datos inicializados en el frame de pila que se copian al espacio de usuario en la función board_info_ioctl. La solución más sencilla es inicializar toda la estructura a cero para garantizar que todos los campos de relleno no asignados se restablezcan a cero antes de copiarse al espacio de usuario.