Vulnerabilidades

composio >=0.5.40 es vulnerable a la ejecución de comandos en composio_openai, composio_claude y composio_julep a través de la función handle_tool_calls.

Se ha encontrado una vulnerabilidad en MicroWorld eScan Antivirus 7.0.32 en Linux. Se ha calificado como crítica. Este problema afecta a una funcionalidad desconocida del archivo /opt/MicroWorld/var/ del componente Installation Handler. La manipulación da lugar a permisos predeterminados incorrectos. El ataque debe abordarse de forma local. El exploit se ha divulgado al público y puede utilizarse. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió de ninguna manera.

Dell VxRail, versiones 8.0.000 a 8.0.311, contiene una vulnerabilidad de almacenamiento de contraseñas en texto plano. Un atacante con privilegios elevados y acceso local podría aprovechar esta vulnerabilidad, lo que provocaría la exposición de información.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/prom_init: Reparación de #size-cells faltantes en powermac. En algunos nodos `escc` faltan las propiedades `#size-cells`, lo cual está obsoleto y ahora activa una advertencia en el arranque desde el commit 045b14ca5c36 ("of: WARN on precated #address-cells/#size-cells management"). Por ejemplo: Falta '#size-cells' en /pci@f2000000/mac-io@c/escc@13000 ADVERTENCIA: CPU: 0 PID: 0 en drivers/of/base.c:133 of_bus_n_size_cells+0x98/0x108 Nombre de hardware: PowerMac3,1 7400 0xc0209 PowerMac ... Seguimiento de llamadas: of_bus_n_size_cells+0x98/0x108 (no confiable) of_bus_default_count_cells+0x40/0x60 __of_get_address+0xc8/0x21c __of_address_to_resource+0x5c/0x228 pmz_init_port+0x5c/0x2ec pmz_probe.isra.0+0x144/0x1e4 pmz_console_init+0x10/0x48 console_init+0xcc/0x138 start_kernel+0x5c4/0x694 Como los powermacs arrancan a través de prom_init, es posible agregar las propiedades faltantes al árbol de dispositivos durante el arranque, evitando la advertencia. Tenga en cuenta que a los nodos `escc-legacy` también les faltan las propiedades `#size-cells`, pero el controlador de Macio las omite, así que déjelas como están. Depende de: 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells management")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: x86: Agregar comprobación de adev NULL a acpi_quirk_skip_serdev_enumeration() acpi_dev_hid_match() no comprueba si adev == NULL, lo desreferencia de forma incondicional. Agregue una comprobación para adev como NULL antes de llamar a acpi_dev_hid_match(). En este momento, acpi_quirk_skip_serdev_enumeration() nunca se llama con un controller_parent sin un compañero ACPI, pero más vale prevenir que curar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_socket: eliminar WARN_ON_ONCE en el nivel máximo de cgroup La profundidad máxima de cgroup es INT_MAX de manera predeterminada; hay un conmutador de cgroup para restringir esta profundidad máxima a un valor más razonable para no perjudicar el rendimiento. Elimine WARN_ON_ONCE innecesario al que se puede acceder desde el espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se agregó una verificación del índice de la matriz para evitar la corrupción de la memoria [Por qué y cómo] Los índices de la matriz fuera de los límites causaron corrupción de la memoria. Se agregaron verificaciones para garantizar que el índice de la matriz permanezca dentro de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: Loongson64: DTS: Realmente arregla los nodos de puerto PCIe para ls7a Corrige las advertencias de dtc: arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Advertencia (interrupt_provider): /bus@10000000/pci@1a000000: Se encontró '#interrupt-cells', pero el nodo no es un proveedor de interrupciones arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Advertencia (interrupt_provider): /bus@10000000/pci@1a000000: Se encontró '#interrupt-cells', pero el nodo no es un proveedor de interrupciones arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Advertencia (interrupt_map): Error en el prerrequisito 'interrupt_provider' Y una advertencia de tiempo de ejecución introducida en el commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells management"): ADVERTENCIA: CPU: 0 PID: 1 en drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0 Falta '#address-cells' en /bus@10000000/pci@1a000000/pci_bridge@9,0 La solución es similar a el commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), que ha solucionado el problema para ls2k (a pesar de que su asunto menciona (ls7a).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: imx8m: Sondear el controlador SoC como controlador de plataforma Con driver_async_probe=* en la línea de comandos del kernel, se produce el siguiente seguimiento porque en el hardware i.MX8M Plus, el controlador soc-imx8m.c llama a of_clk_get_by_name(), que devuelve -EPROBE_DEFER porque el controlador de reloj aún no se ha sondeado. Esto no se detectó durante las pruebas regulares sin driver_async_probe. Convierta el código SoC en controlador de plataforma e instancie un dispositivo de plataforma en su device_initcall() actual para sondear el controlador de plataforma. Reelabore la devolución de llamada .soc_revision para que siempre devuelva un código de error válido y devuelva la revisión de SoC mediante un parámetro. De esta manera, si algo en la devolución de llamada .soc_revision devuelve -EPROBE_DEFER, se propaga a .probe y .probe se volverá a intentar más tarde. " ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 1 en drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180 CPU: 1 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.11.0-next-20240924-00002-g2062bb554dea #603 Nombre del hardware: Kit de desarrollador DH electronics i.MX8M Plus DHCOM Premium (3) (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : imx8mm_soc_revision+0xdc/0x180 lr : imx8mm_soc_revision+0xd0/0x180 sp : ffff8000821fbcc0 x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120 x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311 x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: ffffffffffffffffdfb x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffffff x17: x16: ffff8000823e1000 x15: ffff0000c03b65e8 x14: ffff0000c00051b0 x13: ffff800082790000 x12: 00000000000000801 x11: ffff80008278ffff x10: ffff80008209d3a6 x9: ffff80008062e95c x8: ffff8000821fb9a0 x7: 0000000000000000 x6: 00000000000080e3 x5: ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb Rastreo de llamadas: imx8mm_soc_revision+0xdc/0x180 imx8_soc_init+0xb0/0x1e0 do_one_initcall+0x94/0x1a8 kernel_init_freeable+0x240/0x2a8 kernel_init+0x28/0x140 ret_from_fork+0x10/0x20 ---[ fin del rastreo 000000000000000 ]--- SoC: i.MX8MP revisión 1.1 "

Un paquete 802.15.4 mal formado provoca un desbordamiento del búfer que da lugar a una confirmación y una denegación de servicio. Un restablecimiento del sistema de vigilancia elimina la condición de error automáticamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: poner el programa de bpf_link cuando es seguro desasignarlo En general, se debe considerar que el programa BPF subyacente del enlace BPF es accesible a través de la cadena de gancho de conexión -> enlace -> programa y, de manera pesimista, tenemos que asumir que mientras no sea seguro liberar la memoria del enlace, el código del gancho de conexión podría contener un puntero al programa BPF y usarlo. Como tal, no es (generalmente) correcto poner el programa del enlace antes de esperar a que pasen los GP de RCU. El bpf_prog_put() más ansioso que hacemos actualmente es mayormente correcto debido a que el código de lanzamiento del programa BPF hace una espera similar de GP RCU, pero como se mostrará en los parches siguientes, el programa BPF puede no ser inactivo (y, por lo tanto, depender solo del GP RCU "clásico"), mientras que el gancho de conexión del enlace BPF puede tener semántica inactiva y necesita estar protegido por el Seguimiento de tareas RCU, y para tales casos el enlace BPF tiene que pasar por el Seguimiento de tareas RCU + GP RCU "clásicos" antes de ser desasignado. Y entonces, si ponemos el programa BPF temprano, podríamos liberar el programa BPF antes de liberar el enlace BPF, lo que lleva a una situación de use-after-free. Entonces, este parche pospone bpf_prog_put() hasta que estemos listos para realizar la desasignación de bpf_link. En el peor de los casos, esto retrasa la liberación del programa BPF por un GP RCU adicional, pero eso parece completamente aceptable. Alternativamente, necesitaríamos formas más elaboradas de determinar el gancho BPF, el enlace BPF y la duración del programa BPF, y cómo se relacionan entre sí, lo que parece una complicación innecesaria. Tenga en cuenta que, para la mayoría de los enlaces BPF, seguiremos ejecutando bpf_prog_put() y link dealloc con avidez, por lo que para esos enlaces BPF no hay cambios observables en absoluto. Solo los enlaces BPF que usan dealloc diferido pueden notar una liberación ligeramente retrasada de los programas BPF. Además, para reducir la duplicación de código y lógica, extraiga la lógica de put del programa + link dealloc en el asistente bpf_link_dealloc().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kunit: Se ha corregido una posible desreferencia nula en kunit_device_driver_test(). kunit_kzalloc() puede devolver un puntero NULL. Si se desreferencia sin una comprobación NULL, se puede generar una desreferencia NULL. Se ha añadido una comprobación NULL para test_state.