--- /dev/null
+From f93431c86b631bbca5614c66f966bf3ddb3c2803 Mon Sep 17 00:00:00 2001
+From: Wang Yufen <wangyufen@huawei.com>
+Date: Tue, 7 Jun 2022 20:00:27 +0800
+Subject: ipv6: Fix signed integer overflow in __ip6_append_data
+
+From: Wang Yufen <wangyufen@huawei.com>
+
+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 <hulkci@huawei.com>
+Signed-off-by: Wang Yufen <wangyufen@huawei.com>
+Link: https://lore.kernel.org/r/20220607120028.845916-1-wangyufen@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+[ Conflict due to f37a4cc6bb0b ("udp6: pass flow in ip6_make_skb
+ together with cork") not in the tree ]
+Signed-off-by: Abdelkareem Abdelsaamad <kareemem@amazon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From a8de7f100bb5989d9c3627d3a223ee1c863f3b69 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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 <zoudongjie@huawei.com>
+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 <vkuznets@redhat.com>
+Link: https://lore.kernel.org/r/20250118003454.2619573-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+[ Conflict due to 72167a9d7da2 ("KVM: x86: hyper-v: Stop shadowing
+ global 'current_vcpu' variable") not in the tree ]
+Signed-off-by: Abdelkareem Abdelsaamad <kareemem@amazon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
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
--- /dev/null
+From b3e34a47f98974d0844444c5121aaff123004e57 Mon Sep 17 00:00:00 2001
+From: Baoquan He <bhe@redhat.com>
+Date: Wed, 23 Feb 2022 19:32:24 +0800
+Subject: x86/kexec: fix memory leak of elf header buffer
+
+From: Baoquan He <bhe@redhat.com>
+
+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 <bhe@redhat.com>
+Acked-by: Dave Young <dyoung@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+[ Conflict due to 179350f00e06 ("x86: Use ELF fields defined in 'struct
+ kimage'") not in the tree ]
+Signed-off-by: Abdelkareem Abdelsaamad <kareemem@amazon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
projects / thirdparty / kernel / stable-queue.git / commitdiff
