From: Greg Kroah-Hartman Date: Thu, 13 Mar 2025 16:15:15 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v6.6.84~61 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=7d96f0029bbe522dd64310ff78c4910bed497926;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: ipv6-fix-signed-integer-overflow-in-__ip6_append_data.patch kvm-x86-reject-hyper-v-s-send_ipi-hypercalls-if-local-apic-isn-t-in-kernel.patch x86-kexec-fix-memory-leak-of-elf-header-buffer.patch --- diff --git a/queue-5.10/ipv6-fix-signed-integer-overflow-in-__ip6_append_data.patch b/queue-5.10/ipv6-fix-signed-integer-overflow-in-__ip6_append_data.patch new file mode 100644 index 0000000000..3a1cd8bf97 --- /dev/null +++ b/queue-5.10/ipv6-fix-signed-integer-overflow-in-__ip6_append_data.patch @@ -0,0 +1,111 @@ +From f93431c86b631bbca5614c66f966bf3ddb3c2803 Mon Sep 17 00:00:00 2001 +From: Wang Yufen +Date: Tue, 7 Jun 2022 20:00:27 +0800 +Subject: ipv6: Fix signed integer overflow in __ip6_append_data + +From: Wang Yufen + +commit f93431c86b631bbca5614c66f966bf3ddb3c2803 upstream. + +Resurrect ubsan overflow checks and ubsan report this warning, +fix it by change the variable [length] type to size_t. + +UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:19 +2147479552 + 8567 cannot be represented in type 'int' +CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1 +Hardware name: linux,dummy-virt (DT) +Call trace: + dump_backtrace+0x214/0x230 + show_stack+0x30/0x78 + dump_stack_lvl+0xf8/0x118 + dump_stack+0x18/0x30 + ubsan_epilogue+0x18/0x60 + handle_overflow+0xd0/0xf0 + __ubsan_handle_add_overflow+0x34/0x44 + __ip6_append_data.isra.48+0x1598/0x1688 + ip6_append_data+0x128/0x260 + udpv6_sendmsg+0x680/0xdd0 + inet6_sendmsg+0x54/0x90 + sock_sendmsg+0x70/0x88 + ____sys_sendmsg+0xe8/0x368 + ___sys_sendmsg+0x98/0xe0 + __sys_sendmmsg+0xf4/0x3b8 + __arm64_sys_sendmmsg+0x34/0x48 + invoke_syscall+0x64/0x160 + el0_svc_common.constprop.4+0x124/0x300 + do_el0_svc+0x44/0xc8 + el0_svc+0x3c/0x1e8 + el0t_64_sync_handler+0x88/0xb0 + el0t_64_sync+0x16c/0x170 + +Changes since v1: +-Change the variable [length] type to unsigned, as Eric Dumazet suggested. +Changes since v2: +-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested. +Changes since v3: +-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, as +Jakub Kicinski suggested. + +Reported-by: Hulk Robot +Signed-off-by: Wang Yufen +Link: https://lore.kernel.org/r/20220607120028.845916-1-wangyufen@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +[ Conflict due to f37a4cc6bb0b ("udp6: pass flow in ip6_make_skb + together with cork") not in the tree ] +Signed-off-by: Abdelkareem Abdelsaamad +Signed-off-by: Greg Kroah-Hartman +--- + include/net/ipv6.h | 4 ++-- + net/ipv6/ip6_output.c | 6 +++--- + 2 files changed, 5 insertions(+), 5 deletions(-) + +--- a/include/net/ipv6.h ++++ b/include/net/ipv6.h +@@ -991,7 +991,7 @@ int ip6_find_1stfragopt(struct sk_buff * + int ip6_append_data(struct sock *sk, + int getfrag(void *from, char *to, int offset, int len, + int odd, struct sk_buff *skb), +- void *from, int length, int transhdrlen, ++ void *from, size_t length, int transhdrlen, + struct ipcm6_cookie *ipc6, struct flowi6 *fl6, + struct rt6_info *rt, unsigned int flags); + +@@ -1007,7 +1007,7 @@ struct sk_buff *__ip6_make_skb(struct so + struct sk_buff *ip6_make_skb(struct sock *sk, + int getfrag(void *from, char *to, int offset, + int len, int odd, struct sk_buff *skb), +- void *from, int length, int transhdrlen, ++ void *from, size_t length, int transhdrlen, + struct ipcm6_cookie *ipc6, struct flowi6 *fl6, + struct rt6_info *rt, unsigned int flags, + struct inet_cork_full *cork); +--- a/net/ipv6/ip6_output.c ++++ b/net/ipv6/ip6_output.c +@@ -1449,7 +1449,7 @@ static int __ip6_append_data(struct sock + struct page_frag *pfrag, + int getfrag(void *from, char *to, int offset, + int len, int odd, struct sk_buff *skb), +- void *from, int length, int transhdrlen, ++ void *from, size_t length, int transhdrlen, + unsigned int flags, struct ipcm6_cookie *ipc6) + { + struct sk_buff *skb, *skb_prev = NULL; +@@ -1795,7 +1795,7 @@ error: + int ip6_append_data(struct sock *sk, + int getfrag(void *from, char *to, int offset, int len, + int odd, struct sk_buff *skb), +- void *from, int length, int transhdrlen, ++ void *from, size_t length, int transhdrlen, + struct ipcm6_cookie *ipc6, struct flowi6 *fl6, + struct rt6_info *rt, unsigned int flags) + { +@@ -1989,7 +1989,7 @@ EXPORT_SYMBOL_GPL(ip6_flush_pending_fram + struct sk_buff *ip6_make_skb(struct sock *sk, + int getfrag(void *from, char *to, int offset, + int len, int odd, struct sk_buff *skb), +- void *from, int length, int transhdrlen, ++ void *from, size_t length, int transhdrlen, + struct ipcm6_cookie *ipc6, struct flowi6 *fl6, + struct rt6_info *rt, unsigned int flags, + struct inet_cork_full *cork) diff --git a/queue-5.10/kvm-x86-reject-hyper-v-s-send_ipi-hypercalls-if-local-apic-isn-t-in-kernel.patch b/queue-5.10/kvm-x86-reject-hyper-v-s-send_ipi-hypercalls-if-local-apic-isn-t-in-kernel.patch new file mode 100644 index 0000000000..54aec0a5f6 --- /dev/null +++ b/queue-5.10/kvm-x86-reject-hyper-v-s-send_ipi-hypercalls-if-local-apic-isn-t-in-kernel.patch @@ -0,0 +1,76 @@ +From a8de7f100bb5989d9c3627d3a223ee1c863f3b69 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 17 Jan 2025 16:34:51 -0800 +Subject: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel + +From: Sean Christopherson + +commit a8de7f100bb5989d9c3627d3a223ee1c863f3b69 upstream. + +Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and +only if the local API is emulated/virtualized by KVM, and explicitly reject +said hypercalls if the local APIC is emulated in userspace, i.e. don't rely +on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. + +Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if +Hyper-V enlightenments are exposed to the guest without an in-kernel local +APIC: + + dump_stack+0xbe/0xfd + __kasan_report.cold+0x34/0x84 + kasan_report+0x3a/0x50 + __apic_accept_irq+0x3a/0x5c0 + kvm_hv_send_ipi.isra.0+0x34e/0x820 + kvm_hv_hypercall+0x8d9/0x9d0 + kvm_emulate_hypercall+0x506/0x7e0 + __vmx_handle_exit+0x283/0xb60 + vmx_handle_exit+0x1d/0xd0 + vcpu_enter_guest+0x16b0/0x24c0 + vcpu_run+0xc0/0x550 + kvm_arch_vcpu_ioctl_run+0x170/0x6d0 + kvm_vcpu_ioctl+0x413/0xb20 + __se_sys_ioctl+0x111/0x160 + do_syscal1_64+0x30/0x40 + entry_SYSCALL_64_after_hwframe+0x67/0xd1 + +Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode +can't be modified after vCPUs are created, i.e. if one vCPU has an +in-kernel local APIC, then all vCPUs have an in-kernel local APIC. + +Reported-by: Dongjie Zou +Fixes: 214ff83d4473 ("KVM: x86: hyperv: implement PV IPI send hypercalls") +Fixes: 2bc39970e932 ("x86/kvm/hyper-v: Introduce KVM_GET_SUPPORTED_HV_CPUID") +Cc: stable@vger.kernel.org +Reviewed-by: Vitaly Kuznetsov +Link: https://lore.kernel.org/r/20250118003454.2619573-2-seanjc@google.com +Signed-off-by: Sean Christopherson +[ Conflict due to 72167a9d7da2 ("KVM: x86: hyper-v: Stop shadowing + global 'current_vcpu' variable") not in the tree ] +Signed-off-by: Abdelkareem Abdelsaamad +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/hyperv.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/hyperv.c ++++ b/arch/x86/kvm/hyperv.c +@@ -1618,6 +1618,9 @@ static u64 kvm_hv_send_ipi(struct kvm_vc + u32 vector; + bool all_cpus; + ++ if (!lapic_in_kernel(current_vcpu)) ++ return HV_STATUS_INVALID_HYPERCALL_INPUT; ++ + if (!ex) { + if (!fast) { + if (unlikely(kvm_read_guest(kvm, ingpa, &send_ipi, +@@ -2060,7 +2063,8 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct k + ent->eax |= HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED; + ent->eax |= HV_X64_APIC_ACCESS_RECOMMENDED; + ent->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED; +- ent->eax |= HV_X64_CLUSTER_IPI_RECOMMENDED; ++ if (!vcpu || lapic_in_kernel(vcpu)) ++ ent->eax |= HV_X64_CLUSTER_IPI_RECOMMENDED; + ent->eax |= HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED; + if (evmcs_ver) + ent->eax |= HV_X64_ENLIGHTENED_VMCS_RECOMMENDED; diff --git a/queue-5.10/series b/queue-5.10/series index 038082ecb7..37797885ed 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -1,3 +1,6 @@ vlan-fix-memory-leak-in-vlan_newlink.patch clockevents-drivers-i8253-fix-stop-sequence-for-timer-0.patch sched-isolation-prevent-boot-crash-when-the-boot-cpu-is-nohz_full.patch +ipv6-fix-signed-integer-overflow-in-__ip6_append_data.patch +kvm-x86-reject-hyper-v-s-send_ipi-hypercalls-if-local-apic-isn-t-in-kernel.patch +x86-kexec-fix-memory-leak-of-elf-header-buffer.patch diff --git a/queue-5.10/x86-kexec-fix-memory-leak-of-elf-header-buffer.patch b/queue-5.10/x86-kexec-fix-memory-leak-of-elf-header-buffer.patch new file mode 100644 index 0000000000..0bfaeb0286 --- /dev/null +++ b/queue-5.10/x86-kexec-fix-memory-leak-of-elf-header-buffer.patch @@ -0,0 +1,83 @@ +From b3e34a47f98974d0844444c5121aaff123004e57 Mon Sep 17 00:00:00 2001 +From: Baoquan He +Date: Wed, 23 Feb 2022 19:32:24 +0800 +Subject: x86/kexec: fix memory leak of elf header buffer + +From: Baoquan He + +commit b3e34a47f98974d0844444c5121aaff123004e57 upstream. + +This is reported by kmemleak detector: + +unreferenced object 0xffffc900002a9000 (size 4096): + comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) + hex dump (first 32 bytes): + 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ + 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. + backtrace: + [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 + [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 + [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 + [<0000000019afff23>] crash_load_segments+0x260/0x470 + [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 + [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 + [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 + [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 + [<0000000087c19992>] do_syscall_64+0x3b/0x90 + [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae + +In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to +store elf headers. While it's not freed back to system correctly when +kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it +by introducing x86 specific function arch_kimage_file_post_load_cleanup(), +and freeing the buffer there. + +And also remove the incorrect elf header buffer freeing code. Before +calling arch specific kexec_file loading function, the image instance has +been initialized. So 'image->elf_headers' must be NULL. It doesn't make +sense to free the elf header buffer in the place. + +Three different people have reported three bugs about the memory leak on +x86_64 inside Redhat. + +Link: https://lkml.kernel.org/r/20220223113225.63106-2-bhe@redhat.com +Signed-off-by: Baoquan He +Acked-by: Dave Young +Cc: +Signed-off-by: Andrew Morton +[ Conflict due to 179350f00e06 ("x86: Use ELF fields defined in 'struct + kimage'") not in the tree ] +Signed-off-by: Abdelkareem Abdelsaamad +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/machine_kexec_64.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +--- a/arch/x86/kernel/machine_kexec_64.c ++++ b/arch/x86/kernel/machine_kexec_64.c +@@ -402,9 +402,6 @@ void machine_kexec(struct kimage *image) + #ifdef CONFIG_KEXEC_FILE + void *arch_kexec_kernel_image_load(struct kimage *image) + { +- vfree(image->arch.elf_headers); +- image->arch.elf_headers = NULL; +- + if (!image->fops || !image->fops->load) + return ERR_PTR(-ENOEXEC); + +@@ -540,6 +537,15 @@ overflow: + (int)ELF64_R_TYPE(rel[i].r_info), value); + return -ENOEXEC; + } ++ ++int arch_kimage_file_post_load_cleanup(struct kimage *image) ++{ ++ vfree(image->arch.elf_headers); ++ image->arch.elf_headers = NULL; ++ image->arch.elf_headers_sz = 0; ++ ++ return kexec_image_post_load_cleanup_default(image); ++} + #endif /* CONFIG_KEXEC_FILE */ + + static int