Boletín de vulnerabilidades
Vulnerabilidades con productos recientemente documentados:
No hay vulnerabilidades nuevas para los productos a los que está suscrito.
Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:
-
Vulnerabilidad en HTTP2 en Qt (CVE-2024-39936)
Severidad: Pendiente de análisis
Fecha de publicación: 04/07/2024
Fecha de última actualización: 08/07/2024
Se descubrió un problema en HTTP2 en Qt antes de 5.15.18, 6.x antes de 6.2.13, 6.3.x hasta 6.5.x antes de 6.5.7 y 6.6.x hasta 6.7.x antes de 6.7.3. El código para tomar decisiones relevantes para la seguridad sobre una conexión establecida puede ejecutarse demasiado pronto, porque la señal encrypted() aún no se ha emitido ni procesado.
-
Vulnerabilidad en supOS 5.0 (CVE-2024-39937)
Severidad: Pendiente de análisis
Fecha de publicación: 04/07/2024
Fecha de última actualización: 08/07/2024
supOS 5.0 permite el directory traversal api/image/download?fileName=../ para leer archivos.
-
Vulnerabilidad en rejetto HFS (CVE-2024-39943)
Severidad: Pendiente de análisis
Fecha de publicación: 04/07/2024
Fecha de última actualización: 08/07/2024
rejetto HFS (también conocido como servidor de archivos HTTP) 3 anterior a 0.52.10 en Linux, UNIX y macOS permite la ejecución de comandos del sistema operativo por parte de usuarios remotos autenticados (si tienen permisos de carga). Esto ocurre porque se usa un shell para ejecutar df (es decir, con execSync en lugar de spawnSync en child_process en Node.js).
-
Vulnerabilidad en kernel de Linux (CVE-2023-52340)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
La implementación de IPv6 en el kernel de Linux anterior a 6.3 tiene un umbral net/ipv6/route.c max_size que se puede consumir fácilmente, por ejemplo, provocando una denegación de servicio (errores de red inaccesible) cuando los paquetes IPv6 se envían en un bucle a través de un enchufe crudo.
-
Vulnerabilidad en OpenStack Cinder, Glance y Nova (CVE-2024-32498)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
Se descubrió un problema en OpenStack Cinder hasta 24.0.0, Glance antes de 28.0.2 y Nova antes de 29.0.3. El acceso arbitrario a archivos puede ocurrir a través de datos externos QCOW2 personalizados. Al proporcionar una imagen QCOW2 manipulada que hace referencia a una ruta de archivo de datos específica, un usuario autenticado puede convencer a los sistemas para que devuelvan una copia del contenido de ese archivo desde el servidor, lo que resulta en un acceso no autorizado a datos potencialmente confidenciales. Todas las implementaciones de Cinder y Nova se ven afectadas; solo se ven afectadas las implementaciones de Glance con la conversión de imágenes habilitada.
-
Vulnerabilidad en drupal-wiki.com Drupal Wiki (CVE-2024-34481)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
drupal-wiki.com Drupal Wiki anterior a 8.31.1 permite XSS a través de comentarios, leyendas y títulos de imágenes de una página Wiki.
-
Vulnerabilidad en KSmserver en KDE Plasma Workspace (CVE-2024-36041)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
KSmserver en KDE Plasma Workspace (también conocido como plasma-workspace) anterior a 5.27.11.1 y 6.x anterior a 6.0.5.1 permite conexiones a través de ICE basadas exclusivamente en el host, es decir, se aceptan todas las conexiones locales. Esto permite que otro usuario en la misma máquina obtenga acceso al administrador de sesión, por ejemplo, use la función de restauración de sesión para ejecutar código arbitrario como víctima (en el siguiente inicio) mediante el uso anterior del directorio /tmp.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39472)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfs: corrige la asignación del búfer de recuperación de registros para la corrección heredada de h_size. El commit a70f9fe52daa ("xfs: detecta y maneja el tamaño de iclog no válido establecido por mkfs") agregó una corrección para los valores incorrectos de h_size usados para el registro desmontaje inicial en versiones antiguas de xfsprogs. Posteriormente, el commit 0c771b99d6c9 ("xfs: cálculo de limpieza de bloques de encabezado LR") limpió el cálculo del búfer de recuperación de registros, pero dejó de usar el valor h_size fijo para dimensionar el búfer de recuperación de registros, lo que puede provocar un acceso fuera de los límites cuando el h_size incorrecto no proviene de la antigua herramienta mkfs, sino de un fuzzer. Solucione este problema abriendo la codificación xlog_logrec_hblks y teniendo en cuenta el h_size fijo para este cálculo.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39473)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: ipc4-topology: arregla la consulta de formato de entrada de módulos de proceso sin extensión base. Si un módulo de proceso no tiene extensión de configuración base, entonces se aplica el mismo formato a todas sus entradas. y el proceso->base_config_ext es NULL, lo que provoca una desreferencia NULL cuando se utilizan secuencias y topologías manipuladas específicamente.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39474)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: corrige vmalloc que puede devolver nulo si se llama con __GFP_NOFAIL commit a421ef303008 ("mm: permitir asignaciones !GFP_KERNEL para kvmalloc") incluye soporte para __GFP_NOFAIL, pero presenta un conflicto con el commit dd544141b9eb ("vmalloc: retroceda cuando la tarea actual sea eliminada por OOM"). Un posible escenario es el siguiente: procesar-a __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) __vmalloc_area_node() vm_area_alloc_pages() --> oom-killer envía SIGKILL al proceso-a if (fatal_signal_pending(current)) break; --> devolver NULO; Para solucionar este problema, no marque fatal_signal_pending() en vm_area_alloc_pages() si __GFP_NOFAIL está configurado. Este problema ocurrió durante la PRUEBA DE OPLUS KASAN. A continuación se muestra parte del registro -> oom-killer envía señal para procesar [65731.222840] [T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/ uid_10198,task=gs.intelligence,pid=32454,uid=10198 [65731.259685] [T32454] Rastreo de llamadas: [65731.259698] [T32454] dump_backtrace+0xf4/0x118 [65731.259734] [T32454] pila+0x18/0x24 [65731.259756] [ T32454] dump_stack_lvl+0x60/0x7c [65731.259781] [T32454] dump_stack+0x18/0x38 [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] [65731.259936] T32454] ipanic_die+0x20/0x34 [mrdump] [65731.260019] [ T32454] atomic_notifier_call_chain+0xb4/0xfc [65731.260047] [T32454] notify_die+0x114/0x198 [65731.260073] [T32454] die+0xf4/0x5b4 [65731.260098] [T32454] kernel_fault+0x80/0x98 [65731.260124] [T32454] __do_kernel_fault+0x160/ 0x2a8 [65731.260146] [T32454] do_bad_area+0x68/0x148 [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 [65731.260204] [T32454] x5c [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 [65731.260248] [T32454 ] el1h_64_sync+0x68/0x6c [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 --> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); pánico del kernel por desreferencia del puntero NULL. erofs supone que kvmalloc con __GFP_NOFAIL nunca devuelve NULL. [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 [65731.260339] [T32454] c [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 [65731.260437] [T32454] __do_fault+0xd0/0x33c [65731.260462] [T32454] mm_fault+0xf74/0x3fe0 [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 [ 65731.260509] [T32454] el0_da+0x44/0x94 [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 [65731.260553] [T32454] el0t_64_sync+0x198/0x19c
-
Vulnerabilidad en kernel de Linux (CVE-2024-39475)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: savage: Maneja el retorno de error cuando falla savagefb_check_var. El commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock es igual a cero") verifica el valor de pixclock para evitar división por error cero. Sin embargo, la función savagefb_probe no maneja la devolución de error de savagefb_check_var. Cuando pixclock es 0, provocará un error de división por cero.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39476)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: corrige el punto muerto que raid5d() espera a que se borre MD_SB_CHANGE_PENDING Xiao informó que la prueba lvm2 lvconvert-raid-takeover.sh puede bloquearse con una pequeña posibilidad, la causa principal es exactamente lo mismo que el commit bed9e27baf52 ("Revertir "md/raid5: Espere MD_SB_CHANGE_PENDING en raid5d") Sin embargo, Dan informó otro bloqueo después de eso, y Junxiao investigó el problema y descubrió que esto se debe a que la biografía conectada no puede emitir de raid5d(). La implementación actual en raid5d() tiene una dependencia extraña: 1) md_check_recovery() de raid5d() debe mantener 'reconfig_mutex' para borrar MD_SB_CHANGE_PENDING; 2) raid5d() maneja IO en un bucle muerto, hasta que se emiten todas las IO; 3) IO de raid5d() debe esperar a que se borre MD_SB_CHANGE_PENDING; Este comportamiento se introdujo antes de v2.6 y, como consecuencia, si otro contexto contiene 'reconfig_mutex' y md_check_recovery() no puede actualizar super_block, entonces raid5d() desperdiciará una CPU al 100% mediante el bucle muerto, hasta que 'reconfig_mutex' sea liberado. Consulte la implementación de raid1 y raid10, solucione este problema omitiendo el problema IO si MD_SB_CHANGE_PENDING todavía está configurado después de md_check_recovery(), el hilo del daemon se activará cuando se publique 'reconfig_mutex'. Mientras tanto, el problema de bloqueo también se solucionará.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39477)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/hugetlb: no llame a vma_add_reservation cuando ENOMEM sysbot informó un splat [1] en __unmap_hugepage_range(). Esto se debe a que vma_needs_reservation() puede devolver -ENOMEM si allocate_file_region_entries() no puede asignar la estructura file_region para la reserva. Verifique eso y no llame a vma_add_reservation() si ese es el caso; de lo contrario, region_abort() y region_del() verán que no tenemos ningún file_regions. Si detectamos que vma_needs_reservation() devolvió -ENOMEM, borramos el indicador hugetlb_restore_reserve como si esta reserva todavía estuviera consumida, por lo que free_huge_folio() no incrementará el recuento de resv. [1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa
-
Vulnerabilidad en kernel de Linux (CVE-2024-39478)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: starfive: no liberar el búfer de pila Los datos de texto RSA utilizan un búfer de longitud variable asignado en la pila de software. Llamar a kfree provoca un comportamiento indefinido en operaciones posteriores.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39479)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/hwmon: deshacerse de devm Cuando tanto hwmon como hwmon drvdata (del cual depende hwmon) son recursos administrados por el dispositivo, la expectativa, al desvincular el dispositivo, es que hwmon publicarse antes que drvdata. Sin embargo, en i915 hay dos rutas de código independientes, que liberan drvdata o hwmon y cualquiera de ellas puede publicarse antes que la otra. Estas rutas de código (para desvincular el dispositivo) son las siguientes (consulte también el error al que se hace referencia a continuación): Seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 componente_unbind_all+0x8d/0xa0 componente_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915 ] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 dispositivo_release_driver_internal+0x19c/0x200 store+0x9c/0xb0 y seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_all +0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 Esto significa que en i915, si usa devm, no podemos garantizar que hwmon siempre se publicará antes que drvdata. Lo que significa que tenemos un uaf si se accede a hwmon sysfs cuando drvdata se lanzó pero hwmon no. La única forma de solucionar esto parece ser deshacerse de devm_ y liberar/liberar todo explícitamente durante la desvinculación del dispositivo. v2: Cambiar mensaje de confirmación y otros cambios menores de código v3: Limpieza de i915_hwmon_register en caso de error (Armin Wolf) v4: Eliminar posible advertencia del analizador estático (Rodrigo) Eliminar fetch_and_zero (Jani) v5: Restaurar la lógica anterior para el retorno de error ddat_gt->hwmon_dev (Andi )
-
Vulnerabilidad en kernel de Linux (CVE-2024-39480)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kdb: corrige el desbordamiento del búfer durante la finalización de tabulación Actualmente, cuando el usuario intenta completar el símbolo con la tecla Tab, kdb usará strncpy() para insertar el símbolo completado en el búfer de comando. Desafortunadamente, pasa el tamaño del búfer de origen en lugar del destino a strncpy() con resultados predeciblemente horribles. Lo más obvio es que si el búfer de comando ya está lleno pero cp, la posición del cursor, está en el medio del búfer, entonces escribiremos más allá del final del búfer proporcionado. Solucione este problema reemplazando las dudosas llamadas strncpy() con llamadas memmove()/memcpy() más comprobaciones explícitas de los límites para asegurarnos de que tenemos suficiente espacio antes de comenzar a mover los personajes.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39481)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mc: corrige el recorrido del gráfico en media_pipeline_start El recorrido del gráfico intenta seguir todos los enlaces, incluso si no están entre pads. Esto provoca un bloqueo, por ejemplo, con un enlace MEDIA_LNK_FL_ANCILLARY_LINK. Solucione este problema permitiendo que la caminata continúe solo para los enlaces MEDIA_LNK_FL_DATA_LINK.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39483)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: WARN en la ventana vNMI + NMI si los NMI están completamente enmascarados Al solicitar una ventana NMI, WARN en la ventana de vNMI está habilitado si y solo si los NMI están realmente enmascarados, es decir, si la vCPU ya está manejando una NMI. La ABI de KVM para NMI que llegan simultáneamente (desde el punto de vista de KVM) es inyectar un NMI y esperar el otro. Cuando se usa vNMI, KVM suspende el segundo NMI simplemente configurando V_NMI_PENDING y deja que la CPU haga el resto (el hardware configura automáticamente V_NMI_BLOCKING cuando se inyecta un NMI). Sin embargo, si KVM no puede inyectar inmediatamente una NMI, por ejemplo, porque la vCPU está en una sombra STI o se está ejecutando con GIF=0, entonces KVM solicitará una ventana NMI y activará el WARN (pero seguirá funcionando correctamente). Es discutible si el caso GIF=0 tiene sentido o no, ya que la intención del comportamiento de KVM es proporcionar una funcionalidad lo más cercana posible al hardware real. Por ejemplo, si se envían dos NMI en rápida sucesión, la probabilidad de que ambos NMI lleguen a una sombra de STI es infinitamente baja en hardware real, pero significativamente mayor en un entorno virtual, por ejemplo, si la vCPU tiene prioridad en la sombra de STI. Para GIF=0, el argumento no es tan claro, porque la ventana donde dos NMI pueden colisionar es mucho mayor en el metal desnudo (aunque aún es pequeña). Dicho esto, KVM no debería tener un comportamiento divergente para el caso GIF=0 en función de si la compatibilidad con vNMI está habilitada o no. Y KVM ha permitido NMI simultáneas con GIF=0 durante más de una década, desde el commit 7460fb4a3400 ("KVM: Reparar NMI simultáneas"). Es decir, el manejo de GIF=0 de KVM no debe modificarse sin una *realmente* buena razón para hacerlo, y si se modifica el comportamiento de KVM, debe hacerse independientemente del soporte de vNMI.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39482)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: corrige el abuso de matriz de longitud variable en btree_iter btree_iter se usa de dos maneras: ya sea asignado en la pila con un tamaño fijo MAX_BSETS, o desde un mempool con un tamaño dinámico basado en el conjunto de caché específico. Anteriormente, la estructura tenía una matriz de longitud fija de tamaño MAX_BSETS que estaba indexada fuera de los límites para los iteradores de tamaño dinámico, lo que provoca que UBSAN se queje. Este parche utiliza el mismo enfoque que en sort_iter de bcachefs y divide el iterador en un btree_iter con un miembro de matriz flexible y un btree_iter_stack que incorpora un btree_iter así como una matriz de datos de longitud fija.
-
Vulnerabilidad en kernel de Linux (CVE-2024-39484)
Severidad: Pendiente de análisis
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: davinci: no eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_MMC_DAVINCI=y. Cuando un dispositivo de este tipo se desvincula (por ejemplo, usando sysfs o hotplug), el controlador simplemente se elimina sin que se realice la limpieza. Esto da como resultado fugas de recursos. Solucionarlo compilando la devolución de llamada de eliminación incondicionalmente. Esto también corrige una advertencia de modpost W=1: ADVERTENCIA: modpost: drivers/mmc/host/davinci_mmc: falta de coincidencia de sección en referencia: davinci_mmcsd_driver+0x10 (sección: .data) -> davinci_mmcsd_remove (sección: .exit.text)
-
Vulnerabilidad en ZKTeco BioTime (CVE-2024-6523)
Severidad: MEDIA
Fecha de publicación: 05/07/2024
Fecha de última actualización: 08/07/2024
Se encontró una vulnerabilidad en ZKTeco BioTime hasta 9.5.2. Ha sido clasificada como problemática. Una función desconocida del componente system-group-add Handler es afectada por esta vulnerabilidad. La manipulación del argumento usuario con la entrada conduce a cross site scripting. Es posible lanzar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. VDB-270366 es el identificador asignado a esta vulnerabilidad. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.