kernel/linux.git/arch/x86, branch v6.1.178

perf/x86/amd/core: Always use the NMI latency mitigation

2026-07-24T13:55:19+00:00

commit 73a4c02f94a98d94480c3e5c81450215a4da05ba upstream. Commit df4d29732fda ("perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp") fixed handling of late-arriving NMIs but limited the mitigation to processors having X86_FEATURE_PERFCTR_CORE. However, it is unclear if processors without this feature are also affected. When Mediated vPMU is enabled on affected hardware, it is also possible to bypass the fix inside KVM guests if X86_FEATURE_PERFCTR_CORE is removed from the guest CPUID (e.g. using "-cpu host,-perfctr-core" with QEMU). Hence, use the mitigation at all times. Fixes: df4d29732fda ("perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp") Signed-off-by: Sandipan Das Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/29a3c970da289ab8f24282933bdb36545c0403e8.1780325517.git.sandipan.das@amd.com Signed-off-by: Greg Kroah-Hartman

x86/boot: Reject too long acpi_rsdp= values

2026-07-24T13:55:00+00:00

commit d130041a7b96f79cd4c7079a6c2431a6db4c9619 upstream. cmdline_find_option() returns the full length of the parsed acpi_rsdp= value. get_cmdline_acpi_rsdp() then silently truncates values which do not fit in the val[] buffer. Prevent boot_kstrtoul() from parsing a truncated value and then the kernel from silently using the wrong RSDP address, see discussion in Link:. Issue a warning so that the user is aware that s/he supplied a malformed value and can get feedback instead of silent crashes. [ bp: Make commit message more precise. ] Fixes: 3c98e71b42a7 ("x86/boot: Add "acpi_rsdp=" early parsing") Signed-off-by: Thorsten Blum Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260617130417.36651-4-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman

x86/boot: Validate console=uart8250 baud rate to fix early boot hang

2026-07-24T13:55:00+00:00

commit ffa0aa5b625fe0bed7463ac613f8b06676ff4542 upstream. When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang. Fixes: ce0aa5dd20e4 ("x86, setup: Make the setup code also accept console=uart8250") Signed-off-by: Thorsten Blum Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260713194924.126472-3-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman

KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs

2026-07-24T13:54:58+00:00

commit 9285e4070df2c40585c3d7ec9571faa7a2b97e17 upstream. Ignore KVM's internal "service pending PV EOI" request if the vCPU has disabled PV EOIs since the request was made. Asserting that PV EOIs are enabled can fail if reading guest memory in pv_eoi_get_user() fails, i.e. if pv_eoi_test_and_clr_pending() bails early, *and* the vCPU also disables PV EOIs. kernel BUG at arch/x86/kvm/lapic.c:3338! Oops: invalid opcode: 0000 [#1] SMP CPU: 4 UID: 1000 PID: 890 Comm: pv_eoi_test Not tainted 7.0.0-d585aa5894d8-vm #337 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_lapic_sync_from_vapic+0x12b/0x140 [kvm] Call Trace: kvm_arch_vcpu_ioctl_run+0x1075/0x1c30 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0xb40 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- Fixes: ae7a2a3fb6f8 ("KVM: host side for eoi optimization") Cc: stable@vger.kernel.org Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260624220516.3033391-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman

x86/platform/olpc: xo15: Drop wakeup source on driver removal

2026-07-24T13:54:45+00:00

[ Upstream commit cc966553e6ff0849978b5754531b768b0ff54985 ] Prevent leaking a wakeup source object after removing the driver by adding appropriate cleanup code to its remove callback function. Fixes: a0f30f592d2d ("x86, olpc: Add XO-1.5 SCI driver") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2069931.usQuhbGJ8B@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

mm/fake-numa: fix under-allocation detection in uniform split

2026-07-24T13:54:38+00:00

[ Upstream commit 3a3fc1dfd6a958615ebaab8fb251e89fc2b3f2f2 ] When splitting NUMA node uniformly, split_nodes_size_interleave_uniform() returns the next absolute node ID, not the number of nodes created. The existing under-allocation detection logic compares next absolute node ID (ret) and request count (n), which only works when nid starts at 0. For example, on a system with 2 physical NUMA nodes (node 0: 2GB, node 1: 128MB) and numa=fake=8U, 8 fake nodes are successfully created from node 0 and split_nodes_size_interleave_uniform() returns 8. For node 1, fake node nid starts at 8, but only 4 fake nodes are created due to current FAKE_NODE_MIN_SIZE being 32MB, and split_nodes_size_interleave_uniform() returns 12. By existing under-allocation detection logic, "ret < n" (12 < 8) is false, so the under-allocation will not be detected. Fix under-allocation detection logic to compare the number of actually created nodes (ret - nid) against the request count (n). Also skip under-allocation detection logic for memoryless physical nodes where no fake nodes are created. Also, fix the outdated comment describing split_nodes_size_interleave_uniform() to match the actual return value. Signed-off-by: Sang-Heon Jeon Reported-by: Donghyeon Lee Reported-by: Munhui Chae Fixes: cc9aec03e58f ("x86/numa_emulation: Introduce uniform split capability") # 4.19 Link: https://patch.msgid.link/20260417135805.1758378-1-ekffu200098@gmail.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin

x86/mm: Fix check/use ordering in switch_mm_irqs_off()

2026-07-24T13:54:31+00:00

This is a stable-specific fix. There is no single upstream commit to cherry-pick; the equivalent mainline fix is commit 83b0177a6c48 ("x86/mm: Fix SMP ordering in switch_mm_irqs_off()"), which is in v6.18 but does not apply to these trees because the surrounding code was refactored. The backports of commit fea4e317f9e7 ("x86/mm: Eliminate window where TLB flushes may be inadvertently skipped") -- the fix for CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two code blocks in the wrong order relative to mainline. The fix depends on setting cpu_tlbstate.loaded_mm to LOADED_MM_SWITCHING *before* reading tlb_gen, so that a concurrent TLB shootdown either sees LOADED_MM_SWITCHING and sends the IPI, or the switching CPU sees the updated tlb_gen. In the stable trees the write of LOADED_MM_SWITCHING was placed after the tlb_gen read, so the race window fea4e317f9e7 was meant to close is still open and CVE-2025-37964 is unfixed there: a process can be left running with stale TLB entries, which typically manifests as rare, hard-to-bisect memory corruption or segfaults. This has been confirmed by several independent parties: - reproduced on 6.1.y/6.6.y/6.12.y with the test program in [1], and confirmed fixed by this patch - Seth Forshee saw segfaults on 6.12.y within ~30 minutes of running a test workload; with this patch it ran 18 hours cleanly [2] - Greg Thelen reports 6.6.y- and 6.12.y-based test failures fixed by this patch [3] Dave Hansen acked the patch [4] and has no objection to it going into stable [5]. The patch below is against 6.12.y; the identical change applies to 6.1.y and 6.6.y. (The cpumask_test_cpu()/smp_mb() portion of the mainline fix is not needed here because commit 209954cbc7d0 ("x86/mm/tlb: Update mm_cpumask lazily") was never backported to these trees.) [1] https://lore.kernel.org/lkml/CAHDw0oGd0B4=uuv8NGqbUQ_ZVmSheU2bN70e4QhFXWvuAZdt2w@mail.gmail.com/ [2] https://lore.kernel.org/lkml/aZYWXe739XUJrBld@do-x1carbon/ [3] https://lore.kernel.org/lkml/CAHH2K0brx9omC9QYyB6Lio3t_1Lf8v=VaFoiaG23UgQ-aec89Q@mail.gmail.com/ [4] https://lore.kernel.org/lkml/281e8018-5506-4a79-8775-e0de7e58b95f@intel.com/ [5] https://lore.kernel.org/lkml/86421ee5-5332-46c2-bb48-d40310b818be@intel.com/ Fixes: fea4e317f9e7 ("x86/mm: Eliminate window where TLB flushes may be inadvertently skipped") # 6.1.y/6.6.y/6.12.y backports Acked-by: Dave Hansen Tested-by: Seth Forshee Tested-by: Eric Hagberg Signed-off-by: Stephen Dolan Signed-off-by: Sasha Levin

KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode

2026-07-24T13:54:29+00:00

commit 7ef78d71ca713d8c00f7c34ddcf276c808143f77 upstream. When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f No functional change intended. Reported-by: syzbot ci Closes: https://lore.kernel.org/all/6a2adf3b.3b0a2d4e.8c8d1.0012.GAE@google.com Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260618174347.1981064-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman

KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs

2026-07-24T13:54:29+00:00

commit c5bad4fa2d5dfd8c25140051a9807eba387a19b8 upstream. Move KVM's stuffing of GUEST_PENDING_DBG_EXCEPTIONS.BS when RFLAGS.TF=1 and MOV/POP SS or STI blocking is active into the exception injection code so that KVM fixes up the VMCS for all injected #DBs, not only those that are reflected back into the guest after #DB interception. E.g. if KVM queues a #DB in the emulator, or more importantly if userspace does save/restore exactly on the #DB+shadow boundary, then KVM needs to massage the VMCS to avoid the VM-Entry consistency check. Opportunistically update the wording of the comment to describe the behavior as a workaround of flawed CPU behavior/architecture, to make it clear that the *only* thing KVM is doing is fudging around a consistency check. Per the SDM: There are no pending debug exceptions after VM entry if any of the following are true: * The VM entry is vectoring with one of the following interruption types: external interrupt, non-maskable interrupt (NMI), hardware exception, or privileged software exception. I.e. forcing GUEST_PENDING_DBG_EXCEPTIONS.BS does *not* impact guest- visible behavior. Fixes: b9bed78e2fa9 ("KVM: VMX: Set vmcs.PENDING_DBG.BS on #DB in STI/MOVSS blocking shadow") Cc: stable@vger.kernel.org Reported-by: Hou Wenlong Closes: https://lore.kernel.org/all/b1a294bc9ed4dae532474a5dc6c8cb6e5962de7c.1757416809.git.houwenlong.hwl@antgroup.com Reviewed-by: Hou Wenlong Link: https://patch.msgid.link/20260515222638.1949982-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman

efivarfs: expose used and total size

2026-07-24T13:54:27+00:00

[ Upstream commit d86ff3333cb1d5f42d8898fb5fdb304e143c0237 ] When writing EFI variables, one might get errors with no other message on why it fails. Being able to see how much is used by EFI variables helps analyzing such issues. Since this is not a conventional filesystem, block size is intentionally set to 1 instead of PAGE_SIZE. x86 quirks of reserved size are taken into account; so that available and free size can be different, further helping debugging space issues. With this patch, one can see the remaining space in EFI variable storage via efivarfs, like this: $ df -h /sys/firmware/efi/efivars/ Filesystem Size Used Avail Use% Mounted on efivarfs 176K 106K 66K 62% /sys/firmware/efi/efivars Signed-off-by: Anisse Astier [ardb: - rename efi_reserved_space() to efivar_reserved_space() - whitespace/coding style tweaks] Signed-off-by: Ard Biesheuvel Adjusted for headers in linux-6.1.y Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin