Vulnerabilidades

Logseq es vulnerable a una falla de escape de sandbox donde los plugins que se ejecutan en iframes en sandbox pueden inyectar atributos HTML arbitrarios, como controladores de eventos, en su elemento contenedor en el DOM del host. Debido a una Política de Seguridad de Contenido (CSP) deshabilitada, esto permite que un plugin malicioso ejecute JavaScript arbitrario en el contexto privilegiado del host, obteniendo potencialmente acceso no autorizado a las API del sistema de archivos. Si bien solo la versión v0.10.15 fue probada y confirmada como vulnerable, el estado de otras versiones es desconocido ya que este problema no fue abordado por un parche.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/rxe: Corrección de la conversión iova-a-va para tamaños de página de MR != PAGE_SIZE<br /> <br /> La implementación actual maneja incorrectamente las regiones de memoria (MRs) con tamaños de página diferentes al PAGE_SIZE del sistema. El problema central es que rxe_set_page() se llama con incrementos de paso mr-&gt;page_size, pero la page_list almacena punteros individuales a struct page, cada uno representando PAGE_SIZE de memoria.<br /> <br /> ib_sg_to_page() ha asegurado que cuando i&gt;=1, o bien a) SG[i-1].dma_end y SG[i].dma_addr son contiguos o b) SG[i-1].dma_end y SG[i].dma_addr están alineados con mr-&gt;page_size.<br /> <br /> Esto lleva a una conversión iova-a-va incorrecta en los siguientes escenarios:<br /> <br /> 1) page_size iova = 0x181800<br /> sg[0]: dma_addr=0x181800, len=0x800<br /> sg[1]: dma_addr=0x173000, len=0x1000<br /> <br /> Acceso iova = 0x181800 + 0x810 = 0x182010<br /> VA esperada: 0x173010 (segundo SG, desplazamiento 0x10)<br /> Antes de la corrección:<br /> - índice = (0x182010 &gt;&gt; 12) - (0x181800 &gt;&gt; 12) = 1<br /> - page_offset = 0x182010 &amp; 0xFFF = 0x10<br /> - xarray[1] almacena la base de página del sistema 0x170000<br /> - VA resultante: 0x170000 + 0x10 = 0x170010 (incorrecto)<br /> <br /> 2) page_size &gt; PAGE_SIZE (ej., MR: 64K, sistema: 4K):<br /> ibmr-&gt;iova = 0x18f800<br /> sg[0]: dma_addr=0x18f800, len=0x800<br /> sg[1]: dma_addr=0x170000, len=0x1000<br /> <br /> Acceso iova = 0x18f800 + 0x810 = 0x190010<br /> VA esperada: 0x170010 (segundo SG, desplazamiento 0x10)<br /> Antes de la corrección:<br /> - índice = (0x190010 &gt;&gt; 16) - (0x18f800 &gt;&gt; 16) = 1<br /> - page_offset = 0x190010 &amp; 0xFFFF = 0x10<br /> - xarray[1] almacena la página del sistema para dma_addr 0x170000<br /> - VA resultante: página del sistema de 0x170000 + 0x10 = 0x170010 (incorrecto)<br /> <br /> Yi Zhang informó de un kernel panic[1] hace años relacionado con este defecto.<br /> <br /> Solución:<br /> 1. Reemplazar xarray con un array rxe_mr_page preasignado para indexación secuencial (todos los índices de página de MR son contiguos)<br /> 2. Cada rxe_mr_page almacena tanto struct page como el desplazamiento dentro de la página del sistema<br /> 3. Manejar las relaciones MR page_size != PAGE_SIZE:<br /> - page_size &gt; PAGE_SIZE: Dividir las páginas de MR en múltiples páginas del sistema<br /> - page_size

En el kernel de Linux, la siguiente vulnerabilidad se ha resuelto:<br /> <br /> iio: pressure: mprls0025pa: corrección de la inicialización de la estructura spi_transfer<br /> <br /> Asegúrese de que la estructura spi_transfer se ponga a cero antes de su uso.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dm: corrección de la prueba sin bloqueo para dm_suspended_md<br /> <br /> La función dm_blk_report_zones comprueba si el dispositivo está suspendido con la llamada a &amp;#39;dm_suspended_md&amp;#39;. Sin embargo, esta función es llamada sin mantener ningún bloqueo, por lo que el dispositivo puede ser suspendido justo después de ella.<br /> <br /> Mover la llamada a dm_suspended_md después de dm_get_live_table, para que el dispositivo no pueda ser suspendido después de que se comprobara el estado de suspensión.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> apparmor: corregir rlimit para los temporizadores de CPU posix<br /> <br /> Los temporizadores de CPU posix requieren un paso adicional más allá de establecer el rlimit.<br /> Refactorizar el código para que quede claro cuándo qué código está estableciendo el límite y actualizar condicionalmente los temporizadores de CPU posix cuando sea apropiado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> erofs: manejar el final del sistema de archivos correctamente para montajes respaldados por archivos<br /> <br /> Las solicitudes de E/S más allá del final del sistema de archivos deben ser rellenadas con ceros,<br /> similar a los dispositivos de bucle invertido y eso es lo que esperamos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Revertir net/smc: Introduce TCP ULP support <br /> <br /> Esto revierte el commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.<br /> <br /> Según lo informado por Al Viro, el soporte TCP ULP para SMC está fundamentalmente roto. La implementación intenta convertir un socket TCP activo en un socket SMC modificando in situ la &amp;#39;struct file&amp;#39;, dentry e inode subyacentes, lo que viola las invariantes centrales de VFS que asumen que estas estructuras son inmutables para un archivo abierto, creando un riesgo de errores de uso después de liberar (use after free) e inestabilidad general del sistema.<br /> <br /> Dada la gravedad de este defecto de diseño y el hecho de que existen alternativas más limpias (p. ej., LD_PRELOAD, BPF) para la transparencia de aplicaciones heredadas, el curso de acción correcto es eliminar esta característica por completo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> greybus: gb-beagleplay: almacenamiento en búfer de recepción del cargador de arranque limitado<br /> <br /> cc1352_bootloader_rx() añade cada fragmento de serdev en el rx_buffer fijo antes de analizar los paquetes del cargador de arranque. La función auxiliar puede mantener bytes sobrantes entre retrollamadas y puede recibir múltiples paquetes en una retrollamada, por lo que un único valor de conteo no está limitado por la longitud de un paquete.<br /> <br /> Comprobar que el fragmento entrante cabe en el espacio restante del búfer de recepción antes de memcpy(). Si no es así, descartar los datos preparados y consumir los bytes en lugar de desbordar el rx_buffer.

Se encontró una vulnerabilidad en 389 Directory Server. El plugin de almacenamiento de contraseñas SMD5 realiza un subdesbordamiento de entero sin signo al calcular la longitud del salt a partir de un hash de contraseña manipulado de menos de 16 bytes, lo que provoca una lectura excesiva del búfer que bloquea el servidor LDAP durante la autenticación.

Se encontró un fallo en 389 Directory Server. El plugin de almacenamiento de contraseñas PBKDF2-SHA256 no impone un límite superior en el recuento de iteraciones extraído de los hashes de contraseñas almacenados. Un atacante privilegiado que puede modificar el hash de la contraseña de un usuario puede causar un consumo excesivo de CPU durante la autenticación, lo que provoca una denegación de servicio.

Se encontró una vulnerabilidad de desbordamiento de búfer de montón en 389 Directory Server. Cuando el registro de auditoría está habilitado, la función create_masked_entry_string() en auditlog.c copia una máscara de contraseña de longitud fija en un búfer de montón de tamaño preciso sin verificar el espacio disponible. Si se registra una contraseña corta en texto claro (que requiere almacenamiento de contraseña CLEAR no predeterminado o un par de replicación comprometido), la copia desborda el búfer, corrompiendo la memoria del montón y la salida del registro de auditoría.

Se encontró una vulnerabilidad de desbordamiento de búfer en la pila en 389 Directory Server. La función checkPrefix() en pw.c copia un ID de algoritmo controlado por el atacante en un búfer de pila de 256 bytes sin verificación de límites al analizar valores de atributo cifrados de forma reversible. Un atacante con privilegios de Directory Manager puede provocar la caída del servidor LDAP al almacenar una credencial especialmente diseñada con un ID de algoritmo sobredimensionado. FORTIFY_SOURCE mitiga esto solo a denegación de servicio.