Vulnerabilities

The vulnerability exists in BLUVOYIX due to design flaws in the email sending API. An unauthenticated remote attacker could exploit this vulnerability by sending specially crafted HTTP requests to the vulnerable email sending API. Successful exploitation of this vulnerability could allow the attacker to send unsolicited emails to anyone on behalf of the company.

The vulnerability exists in BLUVOYIX due to an improper password storage implementation and subsequent exposure via unauthenticated APIs. An unauthenticated remote attacker could exploit this vulnerability by sending specially crafted HTTP requests to the vulnerable users API to retrieve the plaintext passwords of all user users. Successful exploitation of this vulnerability could allow the attacker to gain full access to customers' data and completely compromise the targeted platform by logging in using an exposed admin email address and password.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpuset: fix warning when disabling remote partition<br /> <br /> A warning was triggered as follows:<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 /> Call Trace:<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 /> Reproduction steps (on a 16-CPU machine):<br /> <br /> # cd /sys/fs/cgroup/<br /> # mkdir A1<br /> # echo +cpuset &gt; A1/cgroup.subtree_control<br /> # echo "0-14" &gt; A1/cpuset.cpus.exclusive<br /> # mkdir A1/A2<br /> # echo "0-14" &gt; A1/A2/cpuset.cpus.exclusive<br /> # echo "root" &gt; A1/A2/cpuset.cpus.partition<br /> # echo 0 &gt; /sys/devices/system/cpu/cpu15/online<br /> # echo member &gt; A1/A2/cpuset.cpus.partition<br /> <br /> When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs<br /> remain available for the top_cpuset, forcing partitions to share CPUs with<br /> the top_cpuset. In this scenario, disabling the remote partition triggers<br /> a warning stating that effective_xcpus is not a subset of<br /> subpartitions_cpus. Partitions should be invalidated in this case to<br /> inform users that the partition is now invalid(cpus are shared with<br /> top_cpuset).<br /> <br /> To fix this issue:<br /> 1. Only emit the warning only if subpartitions_cpus is not empty and the<br /> effective_xcpus is not a subset of subpartitions_cpus.<br /> 2. During the CPU hotplug process, invalidate partitions if<br /> subpartitions_cpus is empty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: samsung: exynos-clkout: Assign .num before accessing .hws<br /> <br /> Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with<br /> __counted_by") annotated the hws member of &amp;#39;struct clk_hw_onecell_data&amp;#39;<br /> with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS)<br /> about the number of elements in .hws[], so that it can warn when .hws[]<br /> is accessed out of bounds. As noted in that change, the __counted_by<br /> member must be initialized with the number of elements before the first<br /> array access happens, otherwise there will be a warning from each access<br /> prior to the initialization because the number of elements is zero. This<br /> occurs in exynos_clkout_probe() due to .num being assigned after .hws[]<br /> has been accessed:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18<br /> index 0 is out of range for type &amp;#39;clk_hw *[*]&amp;#39;<br /> <br /> Move the .num initialization to before the first access of .hws[],<br /> clearing up the warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: ensure context reset on disconnect()<br /> <br /> After the blamed commit below, if the MPC subflow is already in TCP_CLOSE<br /> status or has fallback to TCP at mptcp_disconnect() time,<br /> mptcp_do_fastclose() skips setting the `send_fastclose flag` and the later<br /> __mptcp_close_ssk() does not reset anymore the related subflow context.<br /> <br /> Any later connection will be created with both the `request_mptcp` flag<br /> and the msk-level fallback status off (it is unconditionally cleared at<br /> MPTCP disconnect time), leading to a warning in 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 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 /> Address the issue setting an explicit `fastclosing` flag at fastclose<br /> time, and checking such flag after mptcp_do_fastclose().

The vulnerability exists in BLUVOYIX due to improper authentication in the BLUVOYIX backend APIs. An unauthenticated remote attacker could exploit this vulnerability by sending specially crafted HTTP requests to the vulnerable APIs. Successful exploitation of this vulnerability could allow the attacker to gain full access to customers&amp;#39; data and completely compromise the targeted platform.

The vulnerability exists in BLUVOYIX due to the exposure of sensitive internal API documentation. An unauthenticated remote attacker could exploit this vulnerability by sending specially crafted HTTP requests to the APIs exposed by the documentation. Successful exploitation of this vulnerability could allow the attacker to cause damage to the targeted platform by abusing internal functionality.

A local user can trigger Harmony SASE Windows client to write or delete files outside the intended certificate working directory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: avoid invalid read in irdma_net_event<br /> <br /> irdma_net_event() should not dereference anything from "neigh" (alias<br /> "ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE.<br /> Other events come with different structures pointed to by "ptr" and they<br /> may be smaller than struct neighbour.<br /> <br /> Move the read of neigh-&gt;dev under the NETEVENT_NEIGH_UPDATE case.<br /> <br /> The bug is mostly harmless, but it triggers KASAN on debug kernels:<br /> <br /> BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma]<br /> Read of size 8 at addr ffffc900075e07f0 by task 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 /> Call Trace:<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 />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt()<br /> <br /> The variable mddev-&gt;private is first assigned to conf and then checked:<br /> <br /> conf = mddev-&gt;private;<br /> if (!conf) ...<br /> <br /> If conf is NULL, then mddev-&gt;private is also NULL. In this case,<br /> null-pointer dereferences can occur when calling raid5_quiesce():<br /> <br /> raid5_quiesce(mddev, true);<br /> raid5_quiesce(mddev, false);<br /> <br /> since mddev-&gt;private is assigned to conf again in raid5_quiesce(), and conf<br /> is dereferenced in several places, for example:<br /> <br /> conf-&gt;quiesce = 0;<br /> wake_up(&amp;conf-&gt;wait_for_quiescent);<br /> <br /> To fix this issue, the function should unlock mddev and return before<br /> invoking raid5_quiesce() when conf is NULL, following the existing pattern<br /> in raid5_change_consistency_policy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()<br /> <br /> It&amp;#39;s possible for cp_read() and hdmi_read() to return -EIO. Those<br /> values are further used as indexes for accessing arrays.<br /> <br /> Fix that by checking return values where it&amp;#39;s needed.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"<br /> <br /> This patch ensures that the RX ring size (rx_pending) is not<br /> set below the permitted length. This avoids UBSAN<br /> shift-out-of-bounds errors when users passes small or zero<br /> ring sizes via ethtool -G.