Vulnerabilities

Failed login response could be different depending on whether the username was local or central.

OpenFlow discovery protocol can exhaust resources because it is not rate limited

Improper limitation of pathname in Circuit Provisioning and File Import applications allows modification and uploading of files

An authenticated user can modify application state data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memblock: Accept allocated memory before use in memblock_double_array()<br /> <br /> When increasing the array size in memblock_double_array() and the slab<br /> is not yet available, a call to memblock_find_in_range() is used to<br /> reserve/allocate memory. However, the range returned may not have been<br /> accepted, which can result in a crash when booting an SNP guest:<br /> <br /> RIP: 0010:memcpy_orig+0x68/0x130<br /> Code: ...<br /> RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006<br /> RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000<br /> RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00<br /> RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000<br /> R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78<br /> R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00<br /> memblock_double_array+0xff/0x310<br /> memblock_add_range+0x1fb/0x2f0<br /> memblock_reserve+0x4f/0xa0<br /> memblock_alloc_range_nid+0xac/0x130<br /> memblock_alloc_internal+0x53/0xc0<br /> memblock_alloc_try_nid+0x3d/0xa0<br /> swiotlb_init_remap+0x149/0x2f0<br /> mem_init+0xb/0xb0<br /> mm_core_init+0x8f/0x350<br /> start_kernel+0x17e/0x5d0<br /> x86_64_start_reservations+0x14/0x30<br /> x86_64_start_kernel+0x92/0xa0<br /> secondary_startup_64_no_verify+0x194/0x19b<br /> <br /> Mitigate this by calling accept_memory() on the memory range returned<br /> before the slab is available.<br /> <br /> Prior to v6.12, the accept_memory() interface used a &amp;#39;start&amp;#39; and &amp;#39;end&amp;#39;<br /> parameter instead of &amp;#39;start&amp;#39; and &amp;#39;size&amp;#39;, therefore the accept_memory()<br /> call must be adjusted to specify &amp;#39;start + size&amp;#39; for &amp;#39;end&amp;#39; when applying<br /> to kernels prior to v6.12.

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 /> ksmbd: fix memory leak in parse_lease_state()<br /> <br /> The previous patch that added bounds check for create lease context<br /> introduced a memory leak. When the bounds check fails, the function<br /> returns NULL without freeing the previously allocated lease_ctx_info<br /> structure.<br /> <br /> This patch fixes the issue by adding kfree(lreq) before returning NULL<br /> in both boundary check cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users<br /> <br /> Support for eBPF programs loaded by unprivileged users is typically<br /> disabled. This means only cBPF programs need to be mitigated for BHB.<br /> <br /> In addition, only mitigate cBPF programs that were loaded by an<br /> unprivileged user. Privileged users can also load the same program<br /> via eBPF, making the mitigation pointless.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Eliminate window where TLB flushes may be inadvertently skipped<br /> <br /> tl;dr: There is a window in the mm switching code where the new CR3 is<br /> set and the CPU should be getting TLB flushes for the new mm. But<br /> should_flush_tlb() has a bug and suppresses the flush. Fix it by<br /> widening the window where should_flush_tlb() sends an IPI.<br /> <br /> Long Version:<br /> <br /> === History ===<br /> <br /> There were a few things leading up to this.<br /> <br /> First, updating mm_cpumask() was observed to be too expensive, so it was<br /> made lazier. But being lazy caused too many unnecessary IPIs to CPUs<br /> due to the now-lazy mm_cpumask(). So code was added to cull<br /> mm_cpumask() periodically[2]. But that culling was a bit too aggressive<br /> and skipped sending TLB flushes to CPUs that need them. So here we are<br /> again.<br /> <br /> === Problem ===<br /> <br /> The too-aggressive code in should_flush_tlb() strikes in this window:<br /> <br /> // Turn on IPIs for this CPU/mm combination, but only<br /> // if should_flush_tlb() agrees:<br /> cpumask_set_cpu(cpu, mm_cpumask(next));<br /> <br /> next_tlb_gen = atomic64_read(&amp;next-&gt;context.tlb_gen);<br /> choose_new_asid(next, next_tlb_gen, &amp;new_asid, &amp;need_flush);<br /> load_new_mm_cr3(need_flush);<br /> // ^ After &amp;#39;need_flush&amp;#39; is set to false, IPIs *MUST*<br /> // be sent to this CPU and not be ignored.<br /> <br /> this_cpu_write(cpu_tlbstate.loaded_mm, next);<br /> // ^ Not until this point does should_flush_tlb()<br /> // become true!<br /> <br /> should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3()<br /> and writing to &amp;#39;loaded_mm&amp;#39;, which is a window where they should not be<br /> suppressed. Whoops.<br /> <br /> === Solution ===<br /> <br /> Thankfully, the fuzzy "just about to write CR3" window is already marked<br /> with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in<br /> should_flush_tlb() is sufficient to ensure that the CPU is targeted with<br /> an IPI.<br /> <br /> This will cause more TLB flush IPIs. But the window is relatively small<br /> and I do not expect this to cause any kind of measurable performance<br /> impact.<br /> <br /> Update the comment where LOADED_MM_SWITCHING is written since it grew<br /> yet another user.<br /> <br /> Peter Z also raised a concern that should_flush_tlb() might not observe<br /> &amp;#39;loaded_mm&amp;#39; and &amp;#39;is_lazy&amp;#39; in the same order that switch_mm_irqs_off()<br /> writes them. Add a barrier to ensure that they are observed in the<br /> order they are written.

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]