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.

Outray openSource ngrok alternative. Prior to 0.1.5, a TOCTOU race condition vulnerability allows a user to exceed the set number of active tunnels in their subscription plan. This vulnerability is fixed in 0.1.5.

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().

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

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.

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 /> mm/page_alloc: change all pageblocks migrate type on coalescing<br /> <br /> When a page is freed it coalesces with a buddy into a higher order page<br /> while possible. When the buddy page migrate type differs, it is expected<br /> to be updated to match the one of the page being freed.<br /> <br /> However, only the first pageblock of the buddy page is updated, while the<br /> rest of the pageblocks are left unchanged.<br /> <br /> That causes warnings in later expand() and other code paths (like below),<br /> since an inconsistency between migration type of the list containing the<br /> page and the page-owned pageblocks migration types is introduced.<br /> <br /> [ 308.986589] ------------[ cut here ]------------<br /> [ 308.987227] page type is 0, passed migratetype is 1 (nr=256)<br /> [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270<br /> [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E)<br /> [ 308.987439] Unloaded tainted modules: hmac_s390(E):2<br /> [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT<br /> [ 308.987657] Tainted: [E]=UNSIGNED_MODULE<br /> [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0)<br /> [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270)<br /> [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3<br /> [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88<br /> [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300<br /> [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008<br /> [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0<br /> [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2 larl %r2,000003499883abd4<br /> 00000349976fa5f6: c0e5ffe3f4b5 brasl %r14,0000034997378f60<br /> #00000349976fa5fc: af000000 mc 0,0<br /> &gt;00000349976fa600: a7f4ff4c brc 15,00000349976fa498<br /> 00000349976fa604: b9040026 lgr %r2,%r6<br /> 00000349976fa608: c0300088317f larl %r3,0000034998800906<br /> 00000349976fa60e: c0e5fffdb6e1 brasl %r14,00000349976b13d0<br /> 00000349976fa614: af000000 mc 0,0<br /> [ 308.987734] Call Trace:<br /> [ 308.987738] [] expand+0x240/0x270<br /> [ 308.987744] ([] expand+0x23c/0x270)<br /> [ 308.987749] [] rmqueue_bulk+0x71e/0x940<br /> [ 308.987754] [] __rmqueue_pcplist+0x1fe/0x2a0<br /> [ 308.987759] [] rmqueue.isra.0+0xb46/0xf40<br /> [ 308.987763] [] get_page_from_freelist+0x198/0x8d0<br /> [ 308.987768] [] __alloc_frozen_pages_noprof+0x198/0x400<br /> [ 308.987774] [] alloc_pages_mpol+0xb8/0x220<br /> [ 308.987781] [] folio_alloc_mpol_noprof+0x26/0xc0<br /> [ 308.987786] [] vma_alloc_folio_noprof+0x6c/0xa0<br /> [ 308.987791] [] vma_alloc_anon_folio_pmd+0x42/0x240<br /> [ 308.987799] [] __do_huge_pmd_anonymous_page+0x3a/0x210<br /> [ 308.987804] [

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().