Vulnerabilities

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/

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.

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.

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.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Sign extend kfunc call arguments<br /> <br /> The kfunc calls are native calls so they should follow LoongArch calling<br /> conventions. Sign extend its arguments properly to avoid kernel panic.<br /> This is done by adding a new emit_abi_ext() helper. The emit_abi_ext()<br /> helper performs extension in place meaning a value already store in the<br /> target register (Note: this is different from the existing sign_extend()<br /> helper and thus we can&amp;#39;t reuse it).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer<br /> <br /> Initialize the eb.vma array with values of 0 when the eb structure is<br /> first set up. In particular, this sets the eb-&gt;vma[i].vma pointers to<br /> NULL, simplifying cleanup and getting rid of the bug described below.<br /> <br /> During the execution of eb_lookup_vmas(), the eb-&gt;vma array is<br /> successively filled up with struct eb_vma objects. This process includes<br /> calling eb_add_vma(), which might fail; however, even in the event of<br /> failure, eb-&gt;vma[i].vma is set for the currently processed buffer.<br /> <br /> If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which<br /> prompts a call to eb_release_vmas() to clean up the mess. Since<br /> eb_lookup_vmas() might fail during processing any (possibly not first)<br /> buffer, eb_release_vmas() checks whether a buffer&amp;#39;s vma is NULL to know<br /> at what point did the lookup function fail.<br /> <br /> In eb_lookup_vmas(), eb-&gt;vma[i].vma is set to NULL if either the helper<br /> function eb_lookup_vma() or eb_validate_vma() fails. eb-&gt;vma[i+1].vma is<br /> set to NULL in case i915_gem_object_userptr_submit_init() fails; the<br /> current one needs to be cleaned up by eb_release_vmas() at this point,<br /> so the next one is set. If eb_add_vma() fails, neither the current nor<br /> the next vma is set to NULL, which is a source of a NULL deref bug<br /> described in the issue linked in the Closes tag.<br /> <br /> When entering eb_lookup_vmas(), the vma pointers are set to the slab<br /> poison value, instead of NULL. This doesn&amp;#39;t matter for the actual<br /> lookup, since it gets overwritten anyway, however the eb_release_vmas()<br /> function only recognizes NULL as the stopping value, hence the pointers<br /> are being set to NULL as they go in case of intermediate failure. This<br /> patch changes the approach to filling them all with NULL at the start<br /> instead, rather than handling that manually during failure.<br /> <br /> (cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: seqiv - Do not use req-&gt;iv after crypto_aead_encrypt<br /> <br /> As soon as crypto_aead_encrypt is called, the underlying request<br /> may be freed by an asynchronous completion. Thus dereferencing<br /> req-&gt;iv after it returns is invalid.<br /> <br /> Instead of checking req-&gt;iv against info, create a new variable<br /> unaligned_info and use it for that purpose instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc91x: fix broken irq-context in PREEMPT_RT<br /> <br /> When smc91x.c is built with PREEMPT_RT, the following splat occurs<br /> in FVP_RevC:<br /> <br /> [ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000<br /> [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106]<br /> [ 13.062137] preempt=0x00000000 lock=0-&gt;0 RCU=0-&gt;1 workfn=mld_ifc_work<br /> [ 13.062266] C<br /> ** replaying previous printk message **<br /> [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}<br /> [ 13.062353] Hardware name: , BIOS<br /> [ 13.062382] Workqueue: mld mld_ifc_work<br /> [ 13.062469] Call trace:<br /> [ 13.062494] show_stack+0x24/0x40 (C)<br /> [ 13.062602] __dump_stack+0x28/0x48<br /> [ 13.062710] dump_stack_lvl+0x7c/0xb0<br /> [ 13.062818] dump_stack+0x18/0x34<br /> [ 13.062926] process_scheduled_works+0x294/0x450<br /> [ 13.063043] worker_thread+0x260/0x3d8<br /> [ 13.063124] kthread+0x1c4/0x228<br /> [ 13.063235] ret_from_fork+0x10/0x20<br /> <br /> This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT,<br /> but smc_special_unlock() does not restore IRQs on PREEMPT_RT.<br /> The reason is that smc_special_unlock() calls spin_unlock_irqrestore(),<br /> and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke<br /> rcu_read_unlock() through __local_bh_enable_ip() when current-&gt;softirq_disable_cnt becomes zero.<br /> <br /> To address this issue, replace smc_special_trylock() with spin_trylock_irqsave().