Vulnerabilidades

La vulnerabilidad existe en BLUVOYIX debido a una autenticación incorrecta en las API de administración de BLUVOYIX. Un atacante remoto no autenticado podría explotar esta vulnerabilidad enviando solicitudes HTTP especialmente diseñadas a la API de administración vulnerable para crear un nuevo usuario con privilegios de administrador. La explotación exitosa de esta vulnerabilidad podría permitir al atacante obtener acceso total a los datos de los clientes y comprometer completamente la plataforma objetivo iniciando sesión con el usuario administrador recién creado.

La vulnerabilidad existe en BLUVOYIX debido a fallos de diseño en la API de envío de correos electrónicos. Un atacante remoto no autenticado podría explotar esta vulnerabilidad enviando solicitudes HTTP especialmente diseñadas a la API de envío de correos electrónicos vulnerable. La explotación exitosa de esta vulnerabilidad podría permitir al atacante enviar correos electrónicos no solicitados a cualquier persona en nombre de la empresa.

La vulnerabilidad existe en BLUVOYIX debido a una implementación inadecuada de almacenamiento de contraseñas y su posterior exposición a través de APIs no autenticadas. Un atacante remoto no autenticado podría explotar esta vulnerabilidad enviando solicitudes HTTP especialmente diseñadas a la API de usuarios vulnerable para recuperar las contraseñas en texto plano de todos los usuarios de usuario. La explotación exitosa de esta vulnerabilidad podría permitir al atacante obtener acceso completo a los datos de los clientes y comprometer completamente la plataforma objetivo iniciando sesión con una dirección de correo electrónico y contraseña de administrador expuestas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cpuset: solucionar advertencia al deshabilitar la partición remota<br /> <br /> Se activó una advertencia de la siguiente manera:<br /> <br /> WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110<br /> RIP: 0010:remote_partition_disable+0xf7/0x110<br /> RSP: 0018:ffffc90001947d88 EFLAGS: 00000206<br /> RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40<br /> RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000<br /> RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8<br /> R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0<br /> Rastro de Llamada:<br /> <br /> update_prstate+0x2d3/0x580<br /> cpuset_partition_write+0x94/0xf0<br /> kernfs_fop_write_iter+0x147/0x200<br /> vfs_write+0x35d/0x500<br /> ksys_write+0x66/0xe0<br /> do_syscall_64+0x6b/0x390<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f55c8cd4887<br /> <br /> Pasos de reproducción (en una máquina de 16 CPU):<br /> <br /> # cd /sys/fs/cgroup/<br /> # mkdir A1<br /> # echo +cpuset &amp;gt; A1/cgroup.subtree_control<br /> # echo "0-14" &amp;gt; A1/cpuset.cpus.exclusive<br /> # mkdir A1/A2<br /> # echo "0-14" &amp;gt; A1/A2/cpuset.cpus.exclusive<br /> # echo "root" &amp;gt; A1/A2/cpuset.cpus.partition<br /> # echo 0 &amp;gt; /sys/devices/system/cpu/cpu15/online<br /> # echo member &amp;gt; A1/A2/cpuset.cpus.partition<br /> <br /> Cuando la CPU 15 se pone fuera de línea, subpartitions_cpus se borra porque no quedan CPU disponibles para el top_cpuset, forzando a las particiones a compartir CPU con el top_cpuset. En este escenario, deshabilitar la partición remota activa una advertencia indicando que effective_xcpus no es un subconjunto de subpartitions_cpus. Las particiones deberían ser invalidadas en este caso para informar a los usuarios que la partición ahora es inválida (las CPU se comparten con top_cpuset).<br /> <br /> Para solucionar este problema:<br /> 1. Solo emitir la advertencia si subpartitions_cpus no está vacío y effective_xcpus no es un subconjunto de subpartitions_cpus.<br /> 2. Durante el proceso de hotplug de CPU, invalidar las particiones si subpartitions_cpus está vacío.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> clk: samsung: exynos-clkout: Asignar .num antes de acceder a .hws<br /> <br /> El commit f316cdff8d67 (&amp;#39;clk: Anotar struct clk_hw_onecell_data con __counted_by&amp;#39;) anotó el miembro hws de &amp;#39;struct clk_hw_onecell_data&amp;#39; con __counted_by, lo que informa al sanitizador de límites (UBSAN_BOUNDS) sobre el número de elementos en .hws[], para que pueda advertir cuando se accede a .hws[] fuera de los límites. Como se señaló en ese cambio, el miembro __counted_by debe inicializarse con el número de elementos antes de que ocurra el primer acceso al array, de lo contrario, habrá una advertencia de cada acceso anterior a la inicialización porque el número de elementos es cero. Esto ocurre en exynos_clkout_probe() debido a que .num se asigna después de que se haya accedido a .hws[]:<br /> <br /> UBSAN: array-index-out-of-bounds en drivers/clk/samsung/clk-exynos-clkout.c:178:18<br /> el índice 0 está fuera de rango para el tipo &amp;#39;clk_hw *[*]&amp;#39;<br /> <br /> Mover la inicialización de .num a antes del primer acceso a .hws[], eliminando la advertencia.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mptcp: asegurar el restablecimiento del contexto en disconnect()<br /> <br /> Después del commit culpado a continuación, si el subflujo MPC ya está en estado TCP_CLOSE o ha recurrido a TCP en el momento de mptcp_disconnect(), mptcp_do_fastclose() omite establecer la bandera &amp;#39;send_fastclose&amp;#39; y el posterior __mptcp_close_ssk() ya no restablece el contexto del subflujo relacionado.<br /> <br /> Cualquier conexión posterior se creará con la bandera &amp;#39;request_mptcp&amp;#39; y el estado de recurso a nivel msk desactivado (se borra incondicionalmente en el momento de la desconexión MPTCP), lo que lleva a una advertencia en subflow_data_ready():<br /> <br /> WARNING: CPU: 26 PID: 8996 at net/mptcp/subflow.c:1519 subflow_data_ready (net/mptcp/subflow.c:1519 (discriminator 13))<br /> Modules linked in:<br /> CPU: 26 UID: 0 PID: 8996 Comm: syz.22.39 Not tainted 6.18.0-rc7-05427-g11fc074f6c36 #1 PREEMPT(voluntary)<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> RIP: 0010:subflow_data_ready (net/mptcp/subflow.c:1519 (discriminator 13))<br /> Code: 90 0f 0b 90 90 e9 04 fe ff ff e8 b7 1e f5 fe 89 ee bf 07 00 00 00 e8 db 19 f5 fe 83 fd 07 0f 84 35 ff ff ff e8 9d 1e f5 fe 90 &amp;lt;0f&amp;gt; 0b 90 e9 27 ff ff ff e8 8f 1e f5 fe 4c 89 e7 48 89 de e8 14 09<br /> RSP: 0018:ffffc9002646fb30 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff88813b218000 RCX: ffffffff825c8435<br /> RDX: ffff8881300b3580 RSI: ffffffff825c8443 RDI: 0000000000000005<br /> RBP: 000000000000000b R08: ffffffff825c8435 R09: 000000000000000b<br /> R10: 0000000000000005 R11: 0000000000000007 R12: ffff888131ac0000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f88330af6c0(0000) GS:ffff888a93dd2000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f88330aefe8 CR3: 000000010ff59000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> tcp_data_ready (net/ipv4/tcp_input.c:5356)<br /> tcp_data_queue (net/ipv4/tcp_input.c:5445)<br /> tcp_rcv_state_process (net/ipv4/tcp_input.c:7165)<br /> tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1955)<br /> __release_sock (include/net/sock.h:1158 (discriminator 6) net/core/sock.c:3180 (discriminator 6))<br /> release_sock (net/core/sock.c:3737)<br /> mptcp_sendmsg (net/mptcp/protocol.c:1763 net/mptcp/protocol.c:1857)<br /> inet_sendmsg (net/ipv4/af_inet.c:853 (discriminator 7))<br /> __sys_sendto (net/socket.c:727 (discriminator 15) net/socket.c:742 (discriminator 15) net/socket.c:2244 (discriminator 15))<br /> __x64_sys_sendto (net/socket.c:2247)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> RIP: 0033:0x7f883326702d<br /> <br /> Abordar el problema estableciendo una bandera &amp;#39;fastclosing&amp;#39; explícita en el momento de fastclose, y verificando dicha bandera después de mptcp_do_fastclose().

La vulnerabilidad existe en BLUVOYIX debido a una autenticación incorrecta en las API de backend de BLUVOYIX. Un atacante remoto no autenticado podría explotar esta vulnerabilidad enviando solicitudes HTTP especialmente diseñadas a las API vulnerables. La explotación exitosa de esta vulnerabilidad podría permitir al atacante obtener acceso completo a los datos de los clientes y comprometer completamente la plataforma objetivo.

La vulnerabilidad existe en BLUVOYIX debido a la exposición de documentación interna sensible de la API. Un atacante remoto no autenticado podría explotar esta vulnerabilidad enviando solicitudes HTTP especialmente diseñadas a las API expuestas por la documentación. La explotación exitosa de esta vulnerabilidad podría permitir al atacante causar daño a la plataforma objetivo al abusar de la funcionalidad interna.

Un usuario local puede desencadenar que el cliente de Harmony SASE para Windows escriba o elimine archivos fuera del directorio de trabajo de certificados previsto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/irdma: evitar lectura inválida en irdma_net_event<br /> <br /> irdma_net_event() no debería desreferenciar nada de &amp;#39;neigh&amp;#39; (alias &amp;#39;ptr&amp;#39;) hasta que haya comprobado que el evento es NETEVENT_NEIGH_UPDATE. Otros eventos vienen con diferentes estructuras apuntadas por &amp;#39;ptr&amp;#39; y pueden ser más pequeñas que struct neighbour.<br /> <br /> Mover la lectura de neigh-&amp;gt;dev bajo el caso NETEVENT_NEIGH_UPDATE.<br /> <br /> El error es mayormente inofensivo, pero activa KASAN en kernels de depuración:<br /> <br /> ERROR: KASAN: desbordamiento de pila en irdma_net_event+0x32e/0x3b0 [irdma]<br /> Lectura de tamaño 8 en la dirección ffffc900075e07f0 por la tarea kworker/27:2/542554<br /> <br /> CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1<br /> Hardware name: [...]<br /> Workqueue: events rt6_probe_deferred<br /> Rastro de Llamada:<br /> <br /> dump_stack_lvl+0x60/0xb0<br /> print_address_description.constprop.0+0x2c/0x3f0<br /> print_report+0xb4/0x270<br /> kasan_report+0x92/0xc0<br /> irdma_net_event+0x32e/0x3b0 [irdma]<br /> notifier_call_chain+0x9e/0x180<br /> atomic_notifier_call_chain+0x5c/0x110<br /> rt6_do_redirect+0xb91/0x1080<br /> tcp_v6_err+0xe9b/0x13e0<br /> icmpv6_notify+0x2b2/0x630<br /> ndisc_redirect_rcv+0x328/0x530<br /> icmpv6_rcv+0xc16/0x1360<br /> ip6_protocol_deliver_rcu+0xb84/0x12e0<br /> ip6_input_finish+0x117/0x240<br /> ip6_input+0xc4/0x370<br /> ipv6_rcv+0x420/0x7d0<br /> __netif_receive_skb_one_core+0x118/0x1b0<br /> process_backlog+0xd1/0x5d0<br /> __napi_poll.constprop.0+0xa3/0x440<br /> net_rx_action+0x78a/0xba0<br /> handle_softirqs+0x2d4/0x9c0<br /> do_softirq+0xad/0xe0<br />

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> md/raid5: corrige posibles desreferencias de puntero nulo en raid5_store_group_thread_cnt()<br /> <br /> La variable mddev-&amp;gt;private se asigna primero a conf y luego se comprueba:<br /> <br /> conf = mddev-&amp;gt;private;<br /> if (!conf) ...<br /> <br /> Si conf es NULL, entonces mddev-&amp;gt;private también es NULL. En este caso,<br /> pueden ocurrir desreferencias de puntero nulo al llamar a raid5_quiesce():<br /> <br /> raid5_quiesce(mddev, true);<br /> raid5_quiesce(mddev, false);<br /> <br /> ya que mddev-&amp;gt;private se asigna a conf de nuevo en raid5_quiesce(), y conf<br /> se desreferencia en varios lugares, por ejemplo:<br /> <br /> conf-&amp;gt;quiesce = 0;<br /> wake_up(&amp;amp;conf-&amp;gt;wait_for_quiescent);<br /> <br /> Para solucionar este problema, la función debería desbloquear mddev y retornar antes de<br /> invocar raid5_quiesce() cuando conf es NULL, siguiendo el patrón existente<br /> en raid5_change_consistency_policy().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: adv7842: Evitar posibles accesos a arrays fuera de límites en adv7842_cp_log_status()<br /> <br /> Es posible que cp_read() y hdmi_read() devuelvan -EIO. Esos valores se utilizan además como índices para acceder a arrays.<br /> <br /> Solucionar esto comprobando los valores de retorno donde sea necesario.<br /> <br /> Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.