Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: fix dereferencing invalid pmd migration entry<br /> <br /> When migrating a THP, concurrent access to the PMD migration entry during<br /> a deferred split scan can lead to an invalid address access, as<br /> illustrated below. To prevent this invalid access, it is necessary to<br /> check the PMD migration entry and return early. In this context, there is<br /> no need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the<br /> equality of the target folio. Since the PMD migration entry is locked, it<br /> cannot be served as the target.<br /> <br /> Mailing list discussion and explanation from Hugh Dickins: "An anon_vma<br /> lookup points to a location which may contain the folio of interest, but<br /> might instead contain another folio: and weeding out those other folios is<br /> precisely what the "folio != pmd_folio((*pmd)" check (and the "risk of<br /> replacing the wrong folio" comment a few lines above it) is for."<br /> <br /> BUG: unable to handle page fault for address: ffffea60001db008<br /> CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60<br /> Call Trace:<br /> <br /> try_to_migrate_one+0x28c/0x3730<br /> rmap_walk_anon+0x4f6/0x770<br /> unmap_folio+0x196/0x1f0<br /> split_huge_page_to_list_to_order+0x9f6/0x1560<br /> deferred_split_scan+0xac5/0x12a0<br /> shrinker_debugfs_scan_write+0x376/0x470<br /> full_proxy_write+0x15c/0x220<br /> vfs_write+0x2fc/0xcb0<br /> ksys_write+0x146/0x250<br /> do_syscall_64+0x6a/0x120<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The bug is found by syzkaller on an internal kernel, then confirmed on<br /> upstream.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Scrub packet on bpf_redirect_peer<br /> <br /> When bpf_redirect_peer is used to redirect packets to a device in<br /> another network namespace, the skb isn&amp;#39;t scrubbed. That can lead skb<br /> information from one namespace to be "misused" in another namespace.<br /> <br /> As one example, this is causing Cilium to drop traffic when using<br /> bpf_redirect_peer to redirect packets that just went through IPsec<br /> decryption to a container namespace. The following pwru trace shows (1)<br /> the packet path from the host&amp;#39;s XFRM layer to the container&amp;#39;s XFRM<br /> layer where it&amp;#39;s dropped and (2) the number of active skb extensions at<br /> each function.<br /> <br /> NETNS MARK IFACE TUPLE FUNC<br /> 4026533547 d00 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 xfrm_rcv_cb<br /> .active_extensions = (__u8)2,<br /> 4026533547 d00 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 xfrm4_rcv_cb<br /> .active_extensions = (__u8)2,<br /> 4026533547 d00 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 gro_cells_receive<br /> .active_extensions = (__u8)2,<br /> [...]<br /> 4026533547 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 skb_do_redirect<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 ip_rcv<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 ip_rcv_core<br /> .active_extensions = (__u8)2,<br /> [...]<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 udp_queue_rcv_one_skb<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 __xfrm_policy_check<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 __xfrm_decode_session<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 security_xfrm_decode_session<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)<br /> .active_extensions = (__u8)2,<br /> <br /> In this case, there are no XFRM policies in the container&amp;#39;s network<br /> namespace so the drop is unexpected. When we decrypt the IPsec packet,<br /> the XFRM state used for decryption is set in the skb extensions. This<br /> information is preserved across the netns switch. When we reach the<br /> XFRM policy check in the container&amp;#39;s netns, __xfrm_policy_check drops<br /> the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM<br /> policy can&amp;#39;t be found that matches the (host-side) XFRM state used for<br /> decryption.<br /> <br /> This patch fixes this by scrubbing the packet when using<br /> bpf_redirect_peer, as is done on typical netns switches via veth<br /> devices except skb-&gt;mark and skb-&gt;tstamp are not zeroed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix uninit-value for saddr in do_output_route4<br /> <br /> syzbot reports for uninit-value for the saddr argument [1].<br /> commit 4754957f04f5 ("ipvs: do not use random local source address for<br /> tunnels") already implies that the input value of saddr<br /> should be ignored but the code is still reading it which can prevent<br /> to connect the route. Fix it by changing the argument to ret_saddr.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147<br /> do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147<br /> __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330<br /> ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136<br /> ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626<br /> nf_hook include/linux/netfilter.h:269 [inline]<br /> __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118<br /> ip_local_out net/ipv4/ip_output.c:127 [inline]<br /> ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501<br /> udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195<br /> udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483<br /> inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x267/0x380 net/socket.c:727<br /> ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620<br /> __sys_sendmmsg+0x41d/0x880 net/socket.c:2702<br /> __compat_sys_sendmmsg net/compat.c:360 [inline]<br /> __do_compat_sys_sendmmsg net/compat.c:367 [inline]<br /> __se_compat_sys_sendmmsg net/compat.c:364 [inline]<br /> __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364<br /> ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346<br /> do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]<br /> __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306<br /> do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369<br /> entry_SYSENTER_compat_after_hwframe+0x84/0x8e<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4167 [inline]<br /> slab_alloc_node mm/slub.c:4210 [inline]<br /> __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367<br /> kmalloc_noprof include/linux/slab.h:905 [inline]<br /> ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]<br /> __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323<br /> ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136<br /> ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626<br /> nf_hook include/linux/netfilter.h:269 [inline]<br /> __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118<br /> ip_local_out net/ipv4/ip_output.c:127 [inline]<br /> ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501<br /> udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195<br /> udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483<br /> inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x267/0x380 net/socket.c:727<br /> ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620<br /> __sys_sendmmsg+0x41d/0x880 net/socket.c:2702<br /> __compat_sys_sendmmsg net/compat.c:360 [inline]<br /> __do_compat_sys_sendmmsg net/compat.c:367 [inline]<br /> __se_compat_sys_sendmmsg net/compat.c:364 [inline]<br /> __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364<br /> ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346<br /> do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]<br /> __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306<br /> do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369<br /> entry_SYSENTER_compat_after_hwframe+0x84/0x8e<br /> <br /> CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)<br /> Hardware name: Google Google Compute Engi<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception<br /> <br /> Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode<br /> on vCPU reset") addressed an issue where a triple fault occurring in<br /> nested mode could lead to use-after-free scenarios. However, the commit<br /> did not handle the analogous situation for System Management Mode (SMM).<br /> <br /> This omission results in triggering a WARN when KVM forces a vCPU INIT<br /> after SHUTDOWN interception while the vCPU is in SMM. This situation was<br /> reprodused using Syzkaller by:<br /> <br /> 1) Creating a KVM VM and vCPU<br /> 2) Sending a KVM_SMI ioctl to explicitly enter SMM<br /> 3) Executing invalid instructions causing consecutive exceptions and<br /> eventually a triple fault<br /> <br /> The issue manifests as follows:<br /> <br /> WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112<br /> kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112<br /> Modules linked in:<br /> CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted<br /> 6.1.130-syzkaller-00157-g164fe5dde9b6 #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112<br /> Call Trace:<br /> <br /> shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136<br /> svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395<br /> svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457<br /> vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline]<br /> vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062<br /> kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283<br /> kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Architecturally, INIT is blocked when the CPU is in SMM, hence KVM&amp;#39;s WARN()<br /> in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper<br /> emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to<br /> do _something_ sane with the VMCB, since it&amp;#39;s technically undefined, and<br /> INIT is the least awful choice given KVM&amp;#39;s ABI.<br /> <br /> So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of<br /> SMM to avoid any weirdness (and the WARN).<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.<br /> <br /> [sean: massage changelog, make it clear this isn&amp;#39;t architectural behavior]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: prevent rename with empty string<br /> <br /> Client can send empty newname string to ksmbd server.<br /> It will cause a kernel oops from d_alloc.<br /> This patch return the error when attempting to rename<br /> a file or directory with an empty new name string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()<br /> <br /> The selftests added to our CI by Bui Quang Minh recently reveals<br /> that there is a mem leak on the error path of virtnet_xsk_pool_enable():<br /> <br /> unreferenced object 0xffff88800a68a000 (size 2048):<br /> comm "xdp_helper", pid 318, jiffies 4294692778<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 0):<br /> __kvmalloc_node_noprof+0x402/0x570<br /> virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882)<br /> xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226)<br /> xsk_bind+0x6a5/0x1ae0<br /> __sys_bind+0x15e/0x230<br /> __x64_sys_bind+0x72/0xb0<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Avoid race in open_cached_dir with lease breaks<br /> <br /> A pre-existing valid cfid returned from find_or_create_cached_dir might<br /> race with a lease break, meaning open_cached_dir doesn&amp;#39;t consider it<br /> valid, and thinks it&amp;#39;s newly-constructed. This leaks a dentry reference<br /> if the allocation occurs before the queued lease break work runs.<br /> <br /> Avoid the race by extending holding the cfid_list_lock across<br /> find_or_create_cached_dir and when the result is checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix UAF in __close_file_table_ids<br /> <br /> A use-after-free is possible if one thread destroys the file<br /> via __ksmbd_close_fd while another thread holds a reference to<br /> it. The existing checks on fp-&gt;refcount are not sufficient to<br /> prevent this.<br /> <br /> The fix takes ft-&gt;lock around the section which removes the<br /> file from the file table. This prevents two threads acquiring the<br /> same file pointer via __close_file_table_ids, as well as the other<br /> functions which retrieve a file from the IDR and which already use<br /> this same lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix panic in failed foilio allocation<br /> <br /> commit 7e119cff9d0a ("ocfs2: convert w_pages to w_folios") and commit<br /> 9a5e08652dc4b ("ocfs2: use an array of folios instead of an array of<br /> pages") save -ENOMEM in the folio array upon allocation failure and call<br /> the folio array free code.<br /> <br /> The folio array free code expects either valid folio pointers or NULL. <br /> Finding the -ENOMEM will result in a panic. Fix by NULLing the error<br /> folio entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sch_htb: make htb_deactivate() idempotent<br /> <br /> Alan reported a NULL pointer dereference in htb_next_rb_node()<br /> after we made htb_qlen_notify() idempotent.<br /> <br /> It turns out in the following case it introduced some regression:<br /> <br /> htb_dequeue_tree():<br /> |-&gt; fq_codel_dequeue()<br /> |-&gt; qdisc_tree_reduce_backlog()<br /> |-&gt; htb_qlen_notify()<br /> |-&gt; htb_deactivate()<br /> |-&gt; htb_next_rb_node()<br /> |-&gt; htb_deactivate()<br /> <br /> For htb_next_rb_node(), after calling the 1st htb_deactivate(), the<br /> clprio[prio]-&gt;ptr could be already set to NULL, which means<br /> htb_next_rb_node() is vulnerable here.<br /> <br /> For htb_deactivate(), although we checked qlen before calling it, in<br /> case of qlen==0 after qdisc_tree_reduce_backlog(), we may call it again<br /> which triggers the warning inside.<br /> <br /> To fix the issues here, we need to:<br /> <br /> 1) Make htb_deactivate() idempotent, that is, simply return if we<br /> already call it before.<br /> 2) Make htb_next_rb_node() safe against ptr==NULL.<br /> <br /> Many thanks to Alan for testing and for the reproducer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Add job to pending list if the reset was skipped<br /> <br /> When a CL/CSD job times out, we check if the GPU has made any progress<br /> since the last timeout. If so, instead of resetting the hardware, we skip<br /> the reset and let the timer get rearmed. This gives long-running jobs a<br /> chance to complete.<br /> <br /> However, when `timedout_job()` is called, the job in question is removed<br /> from the pending list, which means it won&amp;#39;t be automatically freed through<br /> `free_job()`. Consequently, when we skip the reset and keep the job<br /> running, the job won&amp;#39;t be freed when it finally completes.<br /> <br /> This situation leads to a memory leak, as exposed in [1] and [2].<br /> <br /> Similarly to commit 704d3d60fec4 ("drm/etnaviv: don&amp;#39;t block scheduler when<br /> GPU is still active"), this patch ensures the job is put back on the<br /> pending list when extending the timeout.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.