Vulnerabilidades

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

*** 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 /> tracing: Do not register unsupported perf events<br /> <br /> Synthetic events currently do not have a function to register perf events.<br /> This leads to calling the tracepoint register functions with a NULL<br /> function pointer which triggers:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> RIP: 0010:tracepoint_add_func+0x357/0x370<br /> Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f<br /> RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246<br /> RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000<br /> RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8<br /> RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780<br /> R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a<br /> R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78<br /> FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> tracepoint_probe_register+0x5d/0x90<br /> synth_event_reg+0x3c/0x60<br /> perf_trace_event_init+0x204/0x340<br /> perf_trace_init+0x85/0xd0<br /> perf_tp_event_init+0x2e/0x50<br /> perf_try_init_event+0x6f/0x230<br /> ? perf_event_alloc+0x4bb/0xdc0<br /> perf_event_alloc+0x65a/0xdc0<br /> __se_sys_perf_event_open+0x290/0x9f0<br /> do_syscall_64+0x93/0x7b0<br /> ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ? trace_hardirqs_off+0x53/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Instead, have the code return -ENODEV, which doesn&amp;#39;t warn and has perf<br /> error out with:<br /> <br /> # perf record -e synthetic:futex_wait<br /> Error:<br /> The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).<br /> "dmesg | grep -i perf" may provide additional information.<br /> <br /> Ideally perf should support synthetic events, but for now just fix the<br /> warning. The support can come later.

*** 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 /> wifi: mac80211: Discard Beacon frames to non-broadcast address<br /> <br /> Beacon frames are required to be sent to the broadcast address, see IEEE<br /> Std 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frame<br /> shall be set to the broadcast address"). A unicast Beacon frame might be<br /> used as a targeted attack to get one of the associated STAs to do<br /> something (e.g., using CSA to move it to another channel). As such, it<br /> is better have strict filtering for this on the received side and<br /> discard all Beacon frames that are sent to an unexpected address.<br /> <br /> This is even more important for cases where beacon protection is used.<br /> The current implementation in mac80211 is correctly discarding unicast<br /> Beacon frames if the Protected Frame bit in the Frame Control field is<br /> set to 0. However, if that bit is set to 1, the logic used for checking<br /> for configured BIGTK(s) does not actually work. If the driver does not<br /> have logic for dropping unicast Beacon frames with Protected Frame bit<br /> 1, these frames would be accepted in mac80211 processing as valid Beacon<br /> frames even though they are not protected. This would allow beacon<br /> protection to be bypassed. While the logic for checking beacon<br /> protection could be extended to cover this corner case, a more generic<br /> check for discard all Beacon frames based on A1=unicast address covers<br /> this without needing additional changes.<br /> <br /> Address all these issues by dropping received Beacon frames if they are<br /> sent to a non-broadcast address.

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