Vulnerabilities

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

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.