Vulnerabilities

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

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Add missing NULL pointer check for pingpong interface<br /> <br /> It is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a<br /> single place the check is missing.<br /> Also use convenient locals instead of phys_enc-&gt;* where available.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/693860/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel/kexec: fix IMA when allocation happens in CMA area<br /> <br /> *** Bug description ***<br /> <br /> When I tested kexec with the latest kernel, I ran into the following warning:<br /> <br /> [ 40.712410] ------------[ cut here ]------------<br /> [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198<br /> [...]<br /> [ 40.816047] Call trace:<br /> [ 40.818498] kimage_map_segment+0x144/0x198 (P)<br /> [ 40.823221] ima_kexec_post_load+0x58/0xc0<br /> [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368<br /> [...]<br /> [ 40.855423] ---[ end trace 0000000000000000 ]---<br /> <br /> *** How to reproduce ***<br /> <br /> This bug is only triggered when the kexec target address is allocated in<br /> the CMA area. If no CMA area is reserved in the kernel, use the "cma="<br /> option in the kernel command line to reserve one.<br /> <br /> *** Root cause ***<br /> The commit 07d24902977e ("kexec: enable CMA based contiguous<br /> allocation") allocates the kexec target address directly on the CMA area<br /> to avoid copying during the jump. In this case, there is no IND_SOURCE<br /> for the kexec segment. But the current implementation of<br /> kimage_map_segment() assumes that IND_SOURCE pages exist and map them<br /> into a contiguous virtual address by vmap().<br /> <br /> *** Solution ***<br /> If IMA segment is allocated in the CMA area, use its page_address()<br /> directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Use spinlock for context list protection lock<br /> <br /> Previously a mutex was added to protect the encoder and decoder context<br /> lists from unexpected changes originating from the SCP IP block, causing<br /> the context pointer to go invalid, resulting in a NULL pointer<br /> dereference in the IPI handler.<br /> <br /> Turns out on the MT8173, the VPU IPI handler is called from hard IRQ<br /> context. This causes a big warning from the scheduler. This was first<br /> reported downstream on the ChromeOS kernels, but is also reproducible<br /> on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though<br /> the actual capture format is not supported, the affected code paths<br /> are triggered.<br /> <br /> Since this lock just protects the context list and operations on it are<br /> very fast, it should be OK to switch to a spinlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tilcdc: Fix removal actions in case of failed probe<br /> <br /> The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers<br /> should only be called when the device has been successfully registered.<br /> Currently, these functions are called unconditionally in tilcdc_fini(),<br /> which causes warnings during probe deferral scenarios.<br /> <br /> [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68<br /> ...<br /> [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108<br /> [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8<br /> [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144<br /> [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc]<br /> [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]<br /> <br /> Fix this by rewriting the failed probe cleanup path using the standard<br /> goto error handling pattern, which ensures that cleanup functions are<br /> only called on successfully initialized resources. Additionally, remove<br /> the now-unnecessary is_registered flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix string copying in parse_apply_sb_mount_options()<br /> <br /> strscpy_pad() can&amp;#39;t be used to copy a non-NUL-term string into a NUL-term<br /> string of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introduce<br /> memtostr() and memtostr_pad()") provides additional information in that<br /> regard. So if this happens, the following warning is observed:<br /> <br /> strnlen: detected buffer overflow: 65 byte read of buffer size 64<br /> WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032<br /> Call Trace:<br /> <br /> __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039<br /> strnlen include/linux/fortify-string.h:235 [inline]<br /> sized_strscpy include/linux/fortify-string.h:309 [inline]<br /> parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline]<br /> __ext4_fill_super fs/ext4/super.c:5261 [inline]<br /> ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706<br /> get_tree_bdev_flags+0x387/0x620 fs/super.c:1636<br /> vfs_get_tree+0x93/0x380 fs/super.c:1814<br /> do_new_mount fs/namespace.c:3553 [inline]<br /> path_mount+0x6ae/0x1f70 fs/namespace.c:3880<br /> do_mount fs/namespace.c:3893 [inline]<br /> __do_sys_mount fs/namespace.c:4103 [inline]<br /> __se_sys_mount fs/namespace.c:4080 [inline]<br /> __x64_sys_mount+0x280/0x300 fs/namespace.c:4080<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Since userspace is expected to provide s_mount_opts field to be at most 63<br /> characters long with the ending byte being NUL-term, use a 64-byte buffer<br /> which matches the size of s_mount_opts, so that strscpy_pad() does its job<br /> properly. Return with error if the user still managed to provide a<br /> non-NUL-term string here.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a6xx: move preempt_prepare_postamble after error check<br /> <br /> Move the call to preempt_prepare_postamble() after verifying that<br /> preempt_postamble_ptr is valid. If preempt_postamble_ptr is NULL,<br /> dereferencing it in preempt_prepare_postamble() would lead to a crash.<br /> <br /> This change avoids calling the preparation function when the<br /> postamble allocation has failed, preventing potential NULL pointer<br /> dereference and ensuring proper error handling.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/687659/