Vulnerabilidades

*** 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.

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

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

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

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: avoid deadlock on fallback while reinjecting<br /> <br /> Jakub reported an MPTCP deadlock at fallback time:<br /> <br /> WARNING: possible recursive locking detected<br /> 6.18.0-rc7-virtme #1 Not tainted<br /> --------------------------------------------<br /> mptcp_connect/20858 is trying to acquire lock:<br /> ff1100001da18b60 (&amp;msk-&gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280<br /> <br /> but task is already holding lock:<br /> ff1100001da18b60 (&amp;msk-&gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;msk-&gt;fallback_lock);<br /> lock(&amp;msk-&gt;fallback_lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 3 locks held by mptcp_connect/20858:<br /> #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0<br /> #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0<br /> #2: ff1100001da18b60 (&amp;msk-&gt;fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0<br /> <br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full)<br /> Hardware name: Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_deadlock_bug.cold+0xc0/0xcd<br /> validate_chain+0x2ff/0x5f0<br /> __lock_acquire+0x34c/0x740<br /> lock_acquire.part.0+0xbc/0x260<br /> _raw_spin_lock_bh+0x38/0x50<br /> __mptcp_try_fallback+0xd8/0x280<br /> mptcp_sendmsg_frag+0x16c2/0x3050<br /> __mptcp_retrans+0x421/0xaa0<br /> mptcp_release_cb+0x5aa/0xa70<br /> release_sock+0xab/0x1d0<br /> mptcp_sendmsg+0xd5b/0x1bc0<br /> sock_write_iter+0x281/0x4d0<br /> new_sync_write+0x3c5/0x6f0<br /> vfs_write+0x65e/0xbb0<br /> ksys_write+0x17e/0x200<br /> do_syscall_64+0xbb/0xfd0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7fa5627cbc5e<br /> Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa<br /> RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e<br /> RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005<br /> RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920<br /> R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9c<br /> <br /> The packet scheduler could attempt a reinjection after receiving an<br /> MP_FAIL and before the infinite map has been transmitted, causing a<br /> deadlock since MPTCP needs to do the reinjection atomically from WRT<br /> fallback.<br /> <br /> Address the issue explicitly avoiding the reinjection in the critical<br /> scenario. Note that this is the only fallback critical section that<br /> could potentially send packets and hit the double-lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erspan: Initialize options_len before referencing options.<br /> <br /> The struct ip_tunnel_info has a flexible array member named<br /> options that is protected by a counted_by(options_len)<br /> attribute.<br /> <br /> The compiler will use this information to enforce runtime bounds<br /> checking deployed by FORTIFY_SOURCE string helpers.<br /> <br /> As laid out in the GCC documentation, the counter must be<br /> initialized before the first reference to the flexible array<br /> member.<br /> <br /> After scanning through the files that use struct ip_tunnel_info<br /> and also refer to options or options_len, it appears the normal<br /> case is to use the ip_tunnel_info_opts_set() helper.<br /> <br /> Said helper would initialize options_len properly before copying<br /> data into options, however in the GRE ERSPAN code a partial<br /> update is done, preventing the use of the helper function.<br /> <br /> Before this change the handling of ERSPAN traffic in GRE tunnels<br /> would cause a kernel panic when the kernel is compiled with<br /> GCC 15+ and having FORTIFY_SOURCE configured:<br /> <br /> memcpy: detected buffer overflow: 4 byte write of buffer size 0<br /> <br /> Call Trace:<br /> <br /> __fortify_panic+0xd/0xf<br /> erspan_rcv.cold+0x68/0x83<br /> ? ip_route_input_slow+0x816/0x9d0<br /> gre_rcv+0x1b2/0x1c0<br /> gre_rcv+0x8e/0x100<br /> ? raw_v4_input+0x2a0/0x2b0<br /> ip_protocol_deliver_rcu+0x1ea/0x210<br /> ip_local_deliver_finish+0x86/0x110<br /> ip_local_deliver+0x65/0x110<br /> ? ip_rcv_finish_core+0xd6/0x360<br /> ip_rcv+0x186/0x1a0<br /> <br /> Reported-at: https://launchpad.net/bugs/2129580