Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** A local user can trigger Harmony SASE Windows client to write or delete files outside the intended certificate working directory.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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] [

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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/

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.