mirror of
https://github.com/torvalds/linux.git
synced 2026-10-15 20:30:02 +02:00
master
52664 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
9aa622dbaa |
Even more x86 fixes:
- Avoid a false positive panic in the #PF handler, if the kernel triggers
a page fault within the asynchronous page fault handler before the flags
are reset. This can happen for example because of a perf NMI.
- Always reset a vCPU's MMU pointer back to the root MMU when loading
nested guest state fails during RSM or KVM_SET_NESTED_STATE. Otherwise,
KVM tries to run a non-nested guest with a nested MMU, which can result
in a NULL pointer dereference attempting to get the nested MMU's pgd
(EPTP or nested CR3).
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmrQj4kUHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroOVGQf/cWZSdm/Ct31wH7UjwZiPkRUNQFMy
Oy8jrGwXd/h/nfVAgF25wY49gx9JopCPHWJ1EU5NPSkOLTDJ+eMNZUfoCMuhDyYS
gbMdvAbAEILKlgBAbC1pWr1fg6kMUQTJilp54elEP9XhKCOBG+KxfYu9BEvbonoc
SvW/lN3RhIfHKLhTaOMwAA55Ta5ypebEUhjzZZXWFduWgOJn2F2L9ur8KlcpGQDq
fXIeZihH0gmz3n00Q2M+F6BhGnNIxalmjvJ0khHHSUuLBUqKmvAPlzAcHwEbENWT
gVGzq5Jr8nCVey6iLoUQu2Y1Tms/t+zFyAJXFsDE0TBCswW3XAX7DG8hxg==
=4PsA
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"Even more x86 fixes:
- Avoid a false positive panic in the #PF handler, if the kernel
triggers a page fault within the asynchronous page fault handler
before the flags are reset.
This can happen for example because of a perf NMI.
- Always reset a vCPU's MMU pointer back to the root MMU when loading
nested guest state fails during RSM or KVM_SET_NESTED_STATE.
Otherwise KVM tries to run a non-nested guest with a nested MMU,
which can result in a NULL pointer dereference attempting to get
the nested MMU's pgd (EPTP or nested CR3)"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry
x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context
|
||
|
|
6a66840a68 |
Hyper-V fixes for 7.3-rc8
-----BEGIN PGP SIGNATURE----- iQFHBAABCgAxFiEEIbPD0id6easf0xsudhRwX5BBoF4FAmrQiJsTHHdlaS5saXVA a2VybmVsLm9yZwAKCRB2FHBfkEGgXp1UB/4uruLK5Zg/Sf4PguV7WgO9hrEYCTnk urzYhnkOB3G8w0/2p9HVVQUXX29E6oz5w5V/h5piPLXNUSLyei119qhIaZx5BbTe EjCbsIMaqSzI3cGojUNEp6F93wl4ztrKFHQ6nELOfJtFu07R9dr00FRjP8qvJdcn IPCTDotMtRseV/ALG6DCfvWxykmmxGG0odKYQKJTT80q8GEPdDDo+p5SL/4RtxtO h+S2VZ21VgHoU4N6qdJH/dFj0g58wwIMYgj5j2mhpiriXPBMVAQjK1kiMRM7n1xP JvhrKoW794vCMJBHFSTPRl2oxUwbLU1FYacshNcIa8TRm9YAnIhO+Nef =Vqks -----END PGP SIGNATURE----- Merge tag 'hyperv-fixes-signed-20261015' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull Hyper-V fixes from Wei Liu: - Typo and comment fixes (Hemanth Selam, Jiangshan Yi) - Update maintainers list (Wei Liu, Long Li) - Two Hyper-V PCI driver fixes (Naman Jain, Sahil Chandna) - Small fixes for core Hyper-V code (Hardik Garg, Michael Kelley, Waiman Long) * tag 'hyperv-fixes-signed-20261015' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: MAINTAINERS: drop KY from Hyper-V maintainers list PCI: hv: Warn when wait_for_response() waits indefinitely PCI: hv: Probe vPCI buses asynchronously MAINTAINERS: remove myself from the Hyper-V entries mshv_vtl: Check per-CPU register page before mmap tools/hv: fix typo "retrive" in comment Drivers: hv: vmbus: fix typo "substract" in comment Drivers: hv: Don't reset VMBus connection state on error/exit paths x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() x86/hyperv: Fix stale comments after stimer message mode removal Drivers: hv: Avoid infinite retry loop in init_vp_index() |
||
|
|
c8f4cfe1cf |
KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry
Reset the vCPU's MMU pointer back to the root MMU if loading L2 state fails in the "not from VM-Entry" case, i.e. when emulating RSM or handling KVM_SET_NESTED_STATE. Failure to unwind the MMU pointer results in KVM trying to run L1 with a nested MMU, and is especially problematic if the vCPU manages to free its nested state before the VM crashes. Constructing the root for a nested EPT MMU goes through vmcs12, which is dynamically allocated/freed when nVMX is enabled/disabled. And so if the nested state is freed with the MMU still pointing at the nested MMU, KVM will hit a NULL pointer deref when attempting to get L1=>L2 EPTP. BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 114a2d067 P4D 111743067 PUD 11141f067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 20 UID: 1000 PID: 1272 Comm: nested_tdp_faul Not tainted 7.3.0-rc4-8c89f11d1a99b-sink-vm #1914 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Call Trace: <TASK> kvm_mmu_load+0xcd/0x870 [kvm] kvm_arch_vcpu_ioctl_run+0x18f5/0x1f80 [kvm] kvm_vcpu_ioctl+0x2c7/0x970 [kvm] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x9c/0x4d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47491b </TASK> Modules linked in: kvm_intel kvm irqbypass CR2: 0000000000000078 ---[ end trace 0000000000000000 ]--- RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel] Cc: David Woodhouse <dwmw2@infradead.org> Fixes: |
||
|
|
81d99abe2b |
x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context
An async #PF "page not present" event arrives through the #PF vector, and its reason sits in the per-CPU apf_reason.flags until __kvm_handle_async_pf() reads and clears it. If an NMI arrives after the event is injected and before the #PF handler reads the flags, and the NMI handler itself takes a #PF, that fault reads and clears the flags belonging to the #PF it interrupted. It then finds interrupts disabled in the NMI context it interrupted, and panics: Kernel panic - not syncing: Host injected async #PF in interrupt disabled region Call Trace: <NMI> panic+0x52/0x60 __kvm_handle_async_pf+0xb0/0xb0 exc_page_fault+0x71/0xb0 asm_exc_page_fault+0x27/0x30 RIP: 0010:__get_user_nocheck_8+0x6/0x20 perf_callchain_user+0x147/0x1a0 get_perf_callchain+0x12d/0x1c0 ... perf_event_nmi_handler+0x26/0x50 exc_nmi+0xe8/0x110 RIP: 0010:asm_exc_page_fault+0x0/0x30 </NMI> The last RIP line shows the NMI landing on the first instruction of the #PF entry. perf with user call chains takes such a fault: the sampling NMI walks the user stack with __get_user(), which faults when a saved frame pointer is not a valid user address or the walk runs off the top of the stack. The same window exists when KVM, running as an L1 hypervisor with DELIVERY_AS_PF_VMEXIT, reads the flags itself after a #PF VM-exit. The NMI entry code saves and restores CR2 for this nesting, but not the async #PF reason. Andy Lutomirski described the race, with perf as the example, when async #PF delivery was reworked in 2020 [1]. Saving and clearing the flags across the NMI, next to CR2, was discussed there but not merged. Since that rework, Linux has stopped setting KVM_ASYNC_PF_SEND_ALWAYS, so the host delivers "page not present" only for user mode faults and a kernel-mode fault in NMI context (including kernel-mode #MC and #DB) cannot be an async page fault. In that case, return without touching the flags so that the interrupted handler finds them intact. Tested on v7.3-rc5 in a 4-vCPU, 2 GiB guest restored from a snapshot whose memory is served on demand through userfaultfd, so that reading it back takes async #PFs, while every thread samples hardware cycles with user call chains and points its frame pointer at an unmapped page. Without this patch the guest panicked as above in 3 of 3 runs. With it, the guest survived 3 of 3 runs of 60 seconds, and the host counted 148,441 to 153,334 kvm_async_pf_not_present events in the first 20 seconds of each. On 6.18.50 the results were the same: the guest panicked without the patch and survived with it. Link: https://lore.kernel.org/all/ed71d0967113a35f670a9625a058b8e6e0b2f104.1583547991.git.luto@kernel.org/ [1] Link: https://lore.kernel.org/all/20211126123145.2772-1-jiangshanlai@gmail.com/ [2] Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: EJ Campbell <ejc3@meta.com> Link: https://patch.msgid.link/CADkxfh-uQTca_6jB1JPDq1MsKffF_UKGQR339oQSJNcoV75GNQ@mail.gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
||
|
|
03741bcea0 |
More x86 fixes:
- Fix a WARN if the SS bit is set in #NPF exit codes; the AMD manual is unclear about whether it can be set when the guest uses CET but the SupervisorShadowStackEn feature (which KVM does not use) is disabled. However, Hyper-V has started using CET now that KVM supports GMET (it wants the two feature in pairs), and that dissolves all the doubts: the SS bit *is* reported and not clearing it causes a WARN and/or a UBSAN splat. - If creating a vCPU ultimately fails, clear its entry in the AVIC Physical ID table used by hardware to perform IPI Virtualization and delivered posted IRQs. I.e. plug the same use-after-free hole related to IPI virtualization and posted IRQs that was fixed for APICv by commit |
||
|
|
e90ab36691 |
KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes
When running Hyper-V from Windows 11, KVM is seeing the SS bit set in nested page fault error codes produced for shadowed NPT. The AMD manual is unclear about when SS is set, including whether it can be set when SupervisorShadowStackEn (bit 6) is not set in the MISC_CTL field of the VMCB. Nevertheless, the unexpected SS bit causes out of bounds accesses in permission_fault(), seen as either WARNs or UBSAN reports: kernel: UBSAN: array-index-out-of-bounds in arch/x86/kvm/mmu.h:225:27 kernel: index 34 is out of range for type 'u16 [16]' (in this case, the page fault error code is 34*2=0x44, i.e. SS|U; the report shows SS|U|W happening as well). Fix the handling of unknown error codes by dropping SS and (with a WARN) any bits not among those that permission_fault() expects to receive. At the same time, given the uncertainty about when hardware sets SS, follow the processor's behavior when constructing the fault's error code, and preserve the SS bit as passed to FNAME(walk_addr_generic). While the behavior is surprising, there's a possibility that Hyper-V expects it (Hyper-V does not even enable CET unless it finds MBEC/GMET!), so retain the information when reflecting the fault to L1 instead of unconditionally discarding it. Bisection shows that this started happening with commit |
||
|
|
bb44efdb08 |
KVM x86 fixed for 7.3-rcN
- If creating a vCPU ultimately fails, clear its entry in the AVIC Physical ID
table used by hardware to perform IPI Virtualization and delivered posted
IRQs. I.e. plug the same use-after-free hole related to IPI virtualization
and posted IRQs that was fixed for APICv by commit
|
||
|
|
87db7795cb |
x86/CPU/AMD: Fix AMD TLBI Erratum #1718
The processor may fail to invalidate a TLB entry while executing an
INVLPGB/TLBSYNC instruction pair.
Detect the erratum and apply a software workaround when a microcode fix
is not present.
Fixes:
|
||
|
|
06ac073129 |
x86 architecture fixes [with an UM fix included]:
- Don't apply va_align to hugetlb mappings on AMD F15h systems
that have custom va_align.bits values (Laurent Wandrebeck)
- Fix PMD teardown handling regression flagged by lockdep
(Mikhail Gavrilov)
- Hide ptrace header register offset macros behind __ASSEMBLER__ or
__FRAME_OFFSETS, to fix user-space build errors that may trigger
if they happen to shadow these short and generic macro names
(Nick Desaulniers)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmrCBfsRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1hhvxAAiRvv7gz6K9VIJ7S24PdQOf8VuiuLT4De
JUxTb6tUJ3VQ9+qk0xKSAg10z603PKn2Ow01znUNV5wTrRcumpkKTk39ut+x9Yl5
qLDeLVTI/NFAkrYajtjPq3OrwZKnLcAYoZaM9cWtZIoIVCBVIDAsJgS7lIJbUjQ8
FVvI4UUFaToM79jBMvAA89QOK5FrwO26/ENZLbRyceHzHnPrw/pYObaWpUhUs3S6
r0OS2NRUacDid3s3SrVJqkJ9siZvS1OdVQZZwSSKz7oNPsk3yH5aqkFrLrCZJNsa
VG3gCtb7ZLe3omFDmW9RzCYo5afbaUNbdHDOtameVoAT4h71cPoBr3mzAWDJiNEq
NFu7ICAt7XP9Kvfoa4k0n4HhbYNxH1VAyoXOAiquqpPtsU+ZtG2HhqwZknrqGxM4
9S127eCrAyGN9CLrYgcnZlALd1HUJ/nGHqdaSVxyxhaJxgxu9e717YmgsxXVl79p
uCASyox64F4JrKr1n7Yp08UwfPvsquc8ViTyxsfHCuHj59hLnLfxPefr6N86Ztdc
97yQhb7tDq7z8S8IUQTJuOtcDuqIUdm/VRg6+8SP+hVZquCW2zo0lla24Yi/cS1+
om89Mfy4l9v+VzkBy2TvNU0cLy0ClK1BQTquHALWFuCDDEmJ4vftc7eWV4VQ+Idh
lQDDgs0Q66g=
=j39M
-----END PGP SIGNATURE-----
Merge tag 'x86-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
- Don't apply va_align to hugetlb mappings on AMD F15h systems
that have custom va_align.bits values (Laurent Wandrebeck)
- Fix PMD teardown handling regression flagged by lockdep
(Mikhail Gavrilov)
- Hide ptrace header register offset macros behind __ASSEMBLER__ or
__FRAME_OFFSETS, to fix user-space build errors that may trigger
if they happen to shadow these short and generic macro names
(Nick Desaulniers)
* tag 'x86-urgent-2026-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
{x86,um}/uapi/ptrace: Guard register offset macros with __ASSEMBLER__ or __FRAME_OFFSETS
x86/mm: Drop unnecessary PMD page copy when freeing
x86/mm: Don't apply va_align to hugetlb mappings on AMD F15h
|
||
|
|
8f150ccedf |
bpf-fixes
-----BEGIN PGP SIGNATURE----- iQJRBAABCgA7FiEE+soXsSLHKoYyzcli6rmadz2vbToFAmq/0m8dHGFsZXhlaS5z dGFyb3ZvaXRvdkBnbWFpbC5jb20ACgkQ6rmadz2vbTpVWxAAgk0avmO+opg/LpC6 vQ6kQO743IkD1uc+jnGcRbOSo1YftUu5W1HY7hpj75MAdzSuScN3sflWyFb8Ng7l AG6HH9drhOIGzEMzc1847fDqM8BYO4DY72ofM/c6tAqlaO6v5EbT2zW/kXm8PPtS sRE60PP0lMh4NCuD2cH9X19GcR44CQXDijioW91hWAg8jxbGKgz9Skw6W+RHqIrH Gi5pkg7OV4Qz5+/XuLpJ0Sd7df8/LMtzAi+B6EG8EfldvkuSMT1vNyS04IKXjGN2 1BWyUhWuIuRs/ReJ7PbkIa+Byc5ToiMmwozLR8X0M2k5iI6lGSIxdjaAUN0W8sIn fk0aIIHhXa7L5Kf/6sOpLX3zESx5f/i+/7GdMFLYRkXiQTLsMBi2lqxvz++wxxak s/MzJ0luOrbYrU53ufb1tNpwX97mYpvu8YLu7PadfEuQuGf4g1yhrjYAu7wltOCo vPOOCm8SSm+WW0BTNkjET7acYP4nXNHxnAx6KI1BPNMVMBa/C/b7PH7BrQhkkIfp Fq1cXL2FFTRLr+CxhU9oDHfTekvSrY58OZG+lputgFSy4JMXahoioXImGWw2TaGP 00ExdJtA5lsTeskNuGoKDT0pZHWpgi0QlbGzdKWq4Qqv2fEOX5PWhgvnrucZ6+Ob +aH1vPjhom3qsWPxLKFKW/UZsN8= =+6qx -----END PGP SIGNATURE----- Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Pull bpf fixes from Alexei Starovoitov: - Fix overflow of backward jump offset in constant blinding (Alexei Starovoitov) - Fix packet range of packet pointers sharing an id when var_off tightens umax of one pointer and not the other (Alexei Starovoitov) - Fix objects stuck in free_by_rcu_ttrace list of bpf memalloc (Alexei Starovoitov) - Fix use-after-free of progs detached from busy trampolines: wait for an RCU tasks grace period before freeing trampoline progs, and patch detached progs out of trampoline images that are still in use (Florent Revest) - Hold map BTF for the memory allocator destructor record to fix UAF in deferred bpf_mem_alloc destruction (Kumar Kartikeya Dwivedi) - Fix missing migration protection in resizable hashtab lookup_and_delete batch operation (Ömer Mete Kaya) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Fix missing migration protection in __rhtab_map_lookup_and_delete_batch() selftests/bpf: Add a test for objects stuck in free_by_rcu_ttrace bpf: Fix objects stuck in free_by_rcu_ttrace bpf: Factor out __do_call_rcu_ttrace() selftests/bpf: Test packet range of pointers sharing an id bpf: Fix packet range of pointers sharing an id selftests/bpf: Detach a trampoline prog while a task sleeps before it bpf: Skip detached progs in trampoline images that are still in use bpf: Wait for an RCU tasks grace period before freeing trampoline progs bpf: Hold map BTF for the memory allocator destructor record bpf: Fix overflow of jump offset in constant blinding |
||
|
|
ac7445c28e |
Random number generator fixes for Linux 7.3-rc6.
-----BEGIN PGP SIGNATURE----- iQJPBAABCAA5FiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmq/uGEbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMiwyAAoJEEn8cBKl3gOumEgQAK0gjA0n40rHWGlmgIJO WTqMZGcbTvVXpPRyEXuNE7tTRsDDopen4UnmDqDGafXkBO1vU1LaxN72JonPjp7O sg4EqCi0iciuiDvLrjwQ1oPtpkL/feyjcNuNzSH/h2E4hJCUcEnyhTpeaRHCm3t4 IGDXqqYYqjAQV4N6dWrzwN5K2oM75IOzccr0hyROkN/DBrqNZtupOco725MKxSsr FGTgoh0a6GlN3Yp+AIjqaHcPca/aUZApPUKmBzoWeqZmSqAmpzUIJgaHsBZAQS88 oMcSh71Fzi2tOepiazjaAK9nZC3Nh2xeRU8cwUtvLvluzYA6wnBhcuTBOqThJmp3 gEYz8yPbvil0aDIhfXB3xW2dxxsHaJrKJDLz0Smhi43D2lLKteQT3BE/2jQQ7OSa 6FcV905hys3lIxlHeCa2wE/7NgiNAy3qE1aazkIKRfI8dRJxIuhogvW3VpKGCAue TwvjfvuoVtkaPAW/gLyDGRsMzrUvGPFa8yVvP5JTPrYQh5P+bEIM8CozWO2ScVcH Cdu0/TDe9TTS5mIwh0CrSX3shV/80bvHTINL14sTAKBGtN0N0vJgA8NSdIYt8OaF 8qDDMg/XV5LY7sbMB3/Kru//wyfUw4LJdYhZSIJ0tZvzaRRIRiZGL1lT+X12PCrq uoaJ4AoDCf/ZiDaVTXEVf+28 =GmSm -----END PGP SIGNATURE----- Merge tag 'random-7.3-rc6-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random Pull random number generator fixes from Jason Donenfeld: - VMGENID memory needs to be mapped with the decrypted tag, so that SEV-SNP machines can boot - A fix for an initialization race in VMGENID, followed by a cleanup - Trivial kernel doc cleanups in siphash and random.c - A fix for a new compilation failure with recent clang on PPC and RISC-V, due to generating an out-of-line memset in the vDSO * tag 'random-7.3-rc6-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: random: vDSO: avoid call to memset() when zeroing reserved parameter random: fix vgetrandom_opaque_params kernel-doc random: vDSO: fix repeated word 'to' in comment siphash: clean up kernel-doc comments virt: vmgenid: move to using dev_set/get_drvdata virt: vmgenid: set driver_data before registering notification handlers virt: vmgenid: remap memory as decrypted |
||
|
|
eb13a1ff27 |
random: vDSO: avoid call to memset() when zeroing reserved parameter
After a recent change in LLVM [1], builds with the random vDSO implementation, such as PowerPC and RISC-V, fail when checking the vDSO: arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported arch/riscv/kernel/vdso/vdso.so.dbg: dynamic relocations are not supported memset() is now generated when zeroing params->reserved for some builds because LLVM has an optimization (now run in more instances) that can recognize at compile time when it is assigning a static value to a contiguous area of memory and turn that into a call to memset(). Both clang and GCC assume memset() is always available [2]. Clang has an internal fiddly hook, -max-store-memset, which we can set to a high number, to disable generating out of line memset calls [3]. Similarly, GCC has -finline-stringops=memset to do the same [4], should this issue ever hit future version of GCC. While these options wouldn't make sense for normal kernel code, it is fine for the extremely limited and intentionally compact vDSO code. Link: |
||
|
|
bd35955b08 |
Crypto library fixes for v7.3-rc6
- Fix a performance regression in certain AES encryption modes on certain architectures, introduced this cycle. - Fix a small performance regression in the x86_64 optimized AES-GCM code, introduced in 6.15. -----BEGIN PGP SIGNATURE----- iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCar6ZLxQcZWJpZ2dlcnNA a2VybmVsLm9yZwAKCRDzXCl4vpKOKzYvAQDtb68vX+UySUeUo+dGaaZWZv03zKEZ QxnsS78p1jvKZgD9FkcqZ6oe2wDPMnpZGV0tg5OpTBfwm+agX08I83tZjQU= =gSeD -----END PGP SIGNATURE----- Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux Pull crypto library fixes from Eric Biggers: - Fix a performance regression in certain AES encryption modes on certain architectures, introduced this cycle - Fix a small performance regression in the x86_64 optimized AES-GCM code, introduced in 6.15 * tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: crypto: aes - Fix undesired override of some optimized AES modes crypto: x86/aes-gcm - fix always true check for last AAD segment |
||
|
|
a940b03cee |
ARM:
- Take a reference on the last IRQ loaded into an LR to prevent it from being freed while running the guest (Marc Zyngier) - Ensure that the ITS MOVALL command only affects LPIs that were previously affined to the source redistributor (Marc Zyngier) - Fix + test for honoring the host's trap configuration when running non-protected VMs while KVM is in protected mode (Fuad Tabba) - Use the host stage-1 mapping granularity for VM_PFNMAP mappings at stage-2 (Mostafa Saleh) x86: Various bugfixes where the guest could do stupid things on purpose to cause problems in the host: - Failed VMRUNs can cause pending TLB flushes to be dropped, and in general some actions done through VMCB control fields have to be redone if VMRUN fails - Toggling MSR interceptions or eVMCS execution controls can cause the host to use a stale MSR permission bitmap - Bad page tables can cause a WARN. Also fix issues in last week's pull request (my fault, for changing email workflow and thus missing feedback sent to kvm@ but not LKML). Generic: - Take kvm_lock when creating vCPUs. For almost two decades everybody thought it was not done for some unspecified performance reasons, but in reality it was only done because kvm_lock was originally a spinlock. This is a better fix than |
||
|
|
b3e6212dea |
KVM: x86: Use active memslots for the per-vCPU MMIO cache
KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit |
||
|
|
97818b2fa7 |
KVM: SEV: Fix page dirtying in sev_gmem_post_populate()
set_page_dirty() requires that the caller holds some kind of lock to
ensure that the page's mapping does not concurrently go away.
That is not the case for a random page we got from get_user_pages_fast(),
so use set_page_dirty_lock().
Fixes:
|
||
|
|
88c15bbd43 |
KVM: SVM: Clear AVIC Physical ID table entry if vCPU creation fails
If vCPU creation fails after kvm_arch_vcpu_create(), the AVIC Physical ID table entry corresponding to that vCPU continues to point to the freed APIC backing page which can result in UAF. Address this by clearing out the corresponding AVIC Physical ID table entry in the vcpu_free() callback, similar to the VMX commit |
||
|
|
12e0d427c3 |
KVM: SVM: Use "is AVIC-addressable" helper to sanity check load()/put()
Use avic_is_addressable_vcpu() instead of open coding a check on the bounds of the allocated table for the sanity checks when loading/putting AVIC state for a vCPU. If KVM botches the allocation, then KVM will already have performed an OOB write in avic_init_backing_page(), i.e. being super paranoid in load()/put() doesn't provide meaningful protection in practice. Cc: Naveen N Rao (AMD) <naveen@kernel.org> Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260923155108.1550622-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> |
||
|
|
86a24feec1 |
KVM: SVM: Add paranoid helper for checking if vCPU is AVIC-addressable
Add a helper to check if a vCPU is addressable by AVIC hardware, i.e. has an APIC ID that fits in the physical ID table, and use the more paranoid helper when determining if a vCPU is compatible with AVIC when initializing the vCPU. KVM is supposed to reject vCPU creation if the vCPU's ID is greater than or equal to max_vcpu_ids, i.e. simply checking the architectural maximum *should* suffice. But piecing together why this is safe is unnecessarily difficult, and there is no meaningful downside to being extra cautious. Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org> Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260923155108.1550622-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> |
||
|
|
226154ea87 |
crypto: x86/aes-gcm - fix always true check for last AAD segment
In gcm_process_assoc(), a segment that is not the last one must have its
length rounded down to a multiple of 16 bytes, as required by the
assembly. The check for a non-last segment is `if (unlikely(assoclen))
/* Not the last segment yet? */` where assoclen is the number of AAD
bytes remaining after the current segment.
Since the conversion to the new scatterwalk API, assoclen is decremented
at the end of the loop body rather than the beginning, so it still
includes the current segment when the check executes, making the check
always true.
As a result the last segment was rounded down as well, causing some
avoidable extra work: an additional memcpy into the temporary buffer and
an additional call into the assembly after the loop. The GCM
authentication tag is unaffected either way, so the self-tests pass and
this went unnoticed. It is purely an efficiency issue rather than a
correctness one.
Fix this by moving the assoclen decrement back to the beginning of the
loop body.
Fixes:
|
||
|
|
17637e1a58
|
bpf: Skip detached progs in trampoline images that are still in use
bpf_tramp_image_put() makes sure a trampoline image is not freed while
a task may still be running in it, but nothing similar is done for the
progs called by that image. Detach drops the last prog reference right
away and the prog is freed after grace periods, on the basis that a
task still in the traced function skips the fexit progs once the nop at
ip_after_call is patched to a jump.
That leaves out a task sleeping in a sleepable prog that runs before
the detached one, which no grace period waits for:
CPU 0 CPU 1
in image I, sleeping in prog S
detach P from I's trampoline
-> new image, bpf_tramp_image_put(I)
bpf_prog_put(P), last ref
grace periods, P freed
back from S
__bpf_prog_enter(P)
call P->bpf_func
If S and P are fexit progs the task is already past the patched jump,
and fentry only images don't have one. On x86 this is an int3 in
poisoned bpf_prog_pack memory:
Oops: int3: 0000 [#1] SMP NOPTI
CPU: 18 UID: 0 PID: 94573 Comm: x169 Not tainted 6.18.44 #1 PREEMPT(lazy)
RIP: 0010:0xffffffffc0601d8d
Call Trace:
<TASK>
? bpf_trampoline_6442515411+0x1a4/0x21b
bpf_lsm_bprm_committed_creds+0x5/0x10
security_bprm_committed_creds+0x5f/0x70
begin_new_exec+0x2d6/0x410
...
We hit this in production when progs attached through trampolines got
detached while their hooks were busy, and it was independently found
with a fuzzer and KASAN.
Have the JITs emit a patchable nop in front of each prog call sequence
and record it in the image. When a prog is detached, patch its nop to a
jump over the call sequence. Progs that stay attached keep running for
the tasks that are in the image, and ip_after_call isn't needed anymore.
The task can be in any image that isn't freed yet, not only in the
current one. It sleeps in image I1 that calls S, P and Q, then P is
detached and the trampoline moves to image I2, then Q is detached and
its call is still in I1. So the trampoline keeps a list of its images
until they are freed, and detaching a prog patches its nop in all of
them. Images hold a reference on the trampoline for that long.
On riscv and loongarch a jump of any range takes several instructions,
and a task preempted in the middle of them could resume into half of the
new sequence. The nop is a single instruction there, patched to a near
branch through arch_bpf_trampoline_skip().
With the extra nops, BPF_MAX_TRAMP_LINKS progs no longer fit in a page
on x86 and arm64 (and already didn't on powerpc), so lower the limit
there like s390 does.
Fixes:
|
||
|
|
973ea70393 |
KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state
Explicitly flush caches after intra-host migration before clearing "SEV
active" on the source VM, as doing cache maintenance afterwards creates a
tiny window where memory reclaim could return memory to the host without
performing a cache flush, e.g. as pointed out by Sashiko:
CPU1 in sev_migrate_from():
src->active = false;
CPU2 running concurrent unmap:
Since active is false, the automatic cache flush in
sev_guest_memory_reclaimed is skipped.
The host frees and reallocates the page.
CPU1 in sev_migrate_from():
sev_writeback_caches(src_kvm);
Executes a hardware cache flush (wbnoinvd), which writes the guest's old
dirty ciphertext over the new page owner's data.
Fixes:
|
||
|
|
8abbc76120 |
KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it
Nullify have_run_cpus when freeing the mask, particularly in the error path
of __sev_guest_init(), so that KVM doesn't have to subtly use sev->active
to track whether or not the mask has been freed. As pointed out by Sashiko,
blindly freeing the mask in sev_vm_destroy() results in a double-free if
the mask is freed if __sev_guest_init() fails.
Throw the logic in a helper as nullifying the pointer is frustratingly
difficult and weird due to have_run_cpus being a single-entry array when
CPUMASK_OFFSTACK=n. Deliberately don't use CPUMASK_VAR_NULL, as it's not
directly assignable when the cpumask is on-stack, e.g. requires using a
local variable and a memcpy(), which is beyond ridiculous. Furthermore,
while clearing the on-stack bitmask is an unnecessary and arguably unwanted
side effect, KVM absolutely relies on '0' being the "null" value given that
the struct is zero-allocated.
Opportunistically add an alloc() helper to pair with free(); there are just
enough call sites to make doing so worthwhile.
Fixes:
|
||
|
|
a661c34fe6 |
{x86,um}/uapi/ptrace: Guard register offset macros with __ASSEMBLER__ or __FRAME_OFFSETS
The register offset macros in <asm/ptrace-abi.h> are guarded by `defined(__ASSEMBLER__) || defined(__FRAME_OFFSETS)` for 64-bit, but were left unguarded for 32-bit. This causes havoc for userspace that happens to use identifiers colliding with these short macro names (e.g., EBX, ECX, EAX, DS, ES, FS, GS, CS, SS). Without this guard, userspace is forced to be super extra careful with include ordering to minimize the chance of collision. Wrap both the 32-bit and 64-bit register definitions under `#if defined(__ASSEMBLER__) || defined(__FRAME_OFFSETS)`, and ensure User-Mode Linux (UML) defines `__FRAME_OFFSETS` for 32-bit as well. Closes: https://github.com/llvm/llvm-project/issues/217413 Assisted-by: LLM Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Tested-by: Elliott Hughes <enh@google.com> Link: https://patch.msgid.link/20260821-ptrace_uapi-v1-1-3de8638a29f2@google.com |
||
|
|
e3ee38c1bc |
x86/mm: Drop unnecessary PMD page copy when freeing
On a box with a discrete GPU, lockdep reports a possible deadlock as
soon as kswapd shrinks the TTM page pool. The immediate cause is an
x86 commit that added an mmap_read_lock() to kernel page protection
munging code.
The huge vmap code holds the same lock over a GFP_KERNEL allocation,
which is a no-no now that reclaim can take it. That allocation is in a
page table *free* path and ends up being for dubious purposes[1].
Basically, it tries to avoid hardware setting Accessed=1 in page table
entries that are unreachable by the hardware, a non-issue.
Remove the PMD copy. Detach the original PMD page at the PUD, flush
the mid-level caches, and free the PTE tables straight from the
detached PMD page. With no allocation left, the locking issue is gone.
Lockdep splat/analysis:
WARNING: possible circular locking dependency detected
7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U
------------------------------------------------------
kswapd0/269 is trying to acquire lock:
((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0
but task is already holding lock:
(pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm]
Chain exists of:
(init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem
The cycle is built from three edges:
1) pool_shrink_rwsem -> (init_mm).mmap_lock
The TTM shrinker restores the caching attribute of every page it
frees, while holding pool_shrink_rwsem:
ttm_pool_shrink()
-> ttm_pool_dispose_list()
-> ttm_pool_free_page()
-> set_pages_wb()
-> change_page_attr_set_clr() [ init_mm mmap read lock ]
2) fs_reclaim -> pool_shrink_rwsem
The same shrinker, called from reclaim.
3) (init_mm).mmap_lock -> fs_reclaim
ioremap() installing a huge PUD mapping over an existing PMD table:
ioremap_page_range()
-> vmap_range_noflush()
-> vmap_try_huge_pud() [ init_mm mmap read lock ]
-> pud_free_pmd_page()
-> __get_free_page(GFP_KERNEL) [ enters reclaim ]
[ dhansen: Lots of changelog munging/trimming and merged comments from my
version of the fix. ]
Fixes:
|
||
|
|
d2457a7e27 |
x86/mm: Don't apply va_align to hugetlb mappings on AMD F15h
get_align_mask() returns huge_page_mask_align() for hugetlbfs, but get_align_bits()
adds va_align.bits regardless, so vm_unmapped_area() returns an address off the huge
page boundary and __unmap_hugepage_range() hits BUG_ON(start & ~huge_page_mask(h)) at
teardown.
This can be triggered on Carrizo and FX-8370E, both hstates.
Pass the file to get_align_bits() and skip the randomisation for hugetlbfs.
[ bp: Massage commit message. ]
Fixes:
|
||
|
|
efb44d93a6 |
x86 fixes:
- Fix preemption bugs in the SVSM vTPM guest implementation
(Melody Wang)
- Fix MCE-triggered hardware debug register corruption on
task migration (Masami Hiramatsu)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmq4zuYRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1iXThAAsqCXcDx+RNrPihj8j4G7qLBx5P7q+8I0
HQ+LWhdIp/wEOSYVUk4GOX4r13bPg1S6BZl9YZlcV8A5uspQdK9hBvVjH+5g21ZH
0GTepgxQs+OawPHWRPrRAmV8HvKKFvnqdDqCor7/HZgiW5aLozfA5+9EmzHcjUHZ
emAWP6gnbliqJLyOHwbMCHSXnPywYaIBwGFAzWiXdkQzCu/SHvkeoQ0xyvCM+aoE
cWGJD6S3MgvUOEtEQGpPNISpyXHRrorfNd3Km2ypzpoNbkYoompVW64+RkGUlHJH
CmRyP/dK5h4Y0NhE8dZH3gn1FjvjPXT399vwkShYpc4LRLcGnLwk6cpVb4DHKwDG
PUQSkV3akXuL/CndoMMcC7HYsYLriC02wiAYKLQGBM+q9O61iLhJin4f/5tvY219
olyU40sPienXzFS+stenFoN46NuVq5tx7+1qURcO1kE8c2dohAixnJ/PVvl/zJCx
+RSKQcW8rONn0aptg9RkKqlKxERpf0hIUCuNfOUmlcTG9q8zpCOkkfwGZ8LHoOFE
P/FQ5uRAy9IF3egl+BUGOPLVlekJ3VxY6Vh6GPP1DwbUQqFoiEMYsfsW5jSgJcfN
zP72bSSx9dKoPfI6dpDN1tUHFDFEsYU0hFWhfn5+Bo1LJdp1s6LZqRzDc4PSXtla
RNrDnMS31sc=
=1sLJ
-----END PGP SIGNATURE-----
Merge tag 'x86-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
- Fix preemption bugs in the SVSM vTPM guest implementation
(Melody Wang)
- Fix MCE-triggered hardware debug register corruption on
task migration (Masami Hiramatsu)
* tag 'x86-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Fix hardware debug register corruption on task migration
x86/sev: Make vTPM SVSM calls preemption-safe
|
||
|
|
5ccda18d1b |
Perf events fixes:
- Fixes for KVM guest PEBS virtualization (Sean Christopherson)
- Fixes for various Intel PMUs related to PEBS data-source
(Dapeng Mi)
- Fix Intel Panther Cove event scheduling constraints (Dapeng Mi)
- Fix Intel DMR/NVL OMR extra registers event scheduling (Dapeng Mi)
- Rename two confusingly named PMU attributes (Dapeng Mi)
- Fix a refcount leak in attach_perf_ctx_data() (Namhyung Kim)
- Fix NULL pointer dereference crash in __perf_pmu_sched_task()
(Puranjay Mohan)
- Fix CPU-wide event scheduling (Puranjay Mohan)
- Fix x86 LBR branch entry generation (Puranjay Mohan)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmq4zGoRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1guAw//U+WiZoWkWv6oFgAg+KrQFPr/OAzyIYOe
Q355hrxdb2yh5+YGkLl/OCte/wIg1JiUq54gUBHPjEBUK8lxenNK2kOo6/Zd8tDx
oGPyX6t0tpiP1O/PMII3yyd6Q7DYVC08TqOYW68r7Jv/fO2qCtBWZY3hxe0otU2/
z+jqcQno3o8DbzfJnlDJb5honJos8CaT5FA+FkZkvjBF4dMWVErQowefdz2Zd78H
Bu/wxmPG+Hej7ownQalps+ZA52KuQboRwJ+NCmas+fbFCcaWRbdDKTPbvEvzBsHT
nybzlmBdneikrM0aNAXtBxJCLNzVrB6ffmKNFnd3CyfXmNtd/zleoqcKZpII2xO3
UqlnwWR+u2JMGscvWiAAtlkdI0K5P4U1sHObhvzyXwgi3LgRZWJoLoIyiYWGcfnW
Mxe3MCTy0wS+AEKRDvzg+rRr4jqTfl0BsHyzaTyTmWwx0LEg+7zwdryeixpXBbwH
qC/SWkr4sfQlO/kVZHGa1sdHTZocRLcLl3YHsLiwQygu3rjNes+olKyPTtbvt9/a
ZePBdcP+84K146VUczNJRAI4qt5b/X2aMvIYYxVvfDF6kiL0GbXgAfhdNVm5BIZF
u5e2Sb6AX3w78V+YaMX1DuF+ZaFrpQd2UKOkBJPLvFnHTQr2eP2Fa6XfVMXnMcDy
U7APgunF6D8=
=Ggeg
-----END PGP SIGNATURE-----
Merge tag 'perf-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf events fixes from Ingo Molnar:
- Fixes for KVM guest PEBS virtualization (Sean Christopherson)
- Fixes for various Intel PMUs related to PEBS data-source (Dapeng Mi)
- Fix Intel Panther Cove event scheduling constraints (Dapeng Mi)
- Fix Intel DMR/NVL OMR extra registers event scheduling (Dapeng Mi)
- Rename two confusingly named PMU attributes (Dapeng Mi)
- Fix a refcount leak in attach_perf_ctx_data() (Namhyung Kim)
- Fix NULL pointer dereference crash in __perf_pmu_sched_task()
(Puranjay Mohan)
- Fix CPU-wide event scheduling (Puranjay Mohan)
- Fix x86 LBR branch entry generation (Puranjay Mohan)
* tag 'perf-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Fill branch entries with a single assignment
perf/core: Run sched_task() for PMUs with only CPU-wide events
perf/core: Fix NULL pmu_ctx passed to pmu->sched_task()
perf/core: Fix a refcount leak in attach_perf_ctx_data()
perf/x86/intel: Rename NVL offcore_rsp attribute to offmodule_rsp
perf/x86/intel: Rename DMR offcore_rsp attribute to offmodule_rsp
perf/x86/intel: Fix precise OMR event scheduling for DMR/NVL
perf/x86/intel: Constrain Panther Cove UOPS_DISPATCHED events to PMCs 0-3
perf/x86/intel: Delete dead NVL PEBS data-source initcall
perf/x86/intel: Fix Panther Cove PEBS data-source snoop states
perf/x86/intel: Remove incorrect Panther Cove PEBS data-source constraints
perf/x86/intel: Remove incorrect LionCove PEBS data-source constraints
perf/x86/intel: Update arw_latency_data() mem-op direction handling
perf/x86/intel: Fix DKT PEBS load/store direction for latency events, to fix sample classification
perf/x86/intel: Fix CMT PEBS load/store direction for latency events, to fix sample classification
perf/x86/intel: Fix GRT PEBS load/store direction for latency events, to fix sample classification
perf/x86/intel: Make @data a mandatory param for intel_guest_get_msrs()
perf/x86/intel: Don't pointlessly context switch DS_AREA (and PEBS config) if PEBS is unused
perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU has PEBS isolation, to fix stuck PEBS_ENABLED
perf/x86/intel: Ensure KVM guest PEBS path doesn't set unwanted PERF_GLOBAL_CTRL bits
|
||
|
|
fddfc3ec31 |
pci-v7.3-fixes-2
-----BEGIN PGP SIGNATURE----- iQJIBAABCgAyFiEEgMe7l+5h9hnxdsnuWYigwDrT+vwFAmq38q4UHGJoZWxnYWFz QGdvb2dsZS5jb20ACgkQWYigwDrT+vwVFhAAhO4zr6WHzB/Tx87FGSxYnjrwzOmH nS/w0MD0FxPkAzhbkPaXkdgAks10dBNF/umQUXvWBwgZYbR9v0CoZBSm8viuq/8C tYOdOm4u4whsHVPU1QJPV5nUSGb2Eiq7vza+2kS1Ll0xy/3/24yVn+IU8sy4EcgX IUTwApHfBGq6se88LxtdT5ctAUCRSP8XAeFlKXqfPig9yrrQOZ0cJrA5nhbe4jCL jJMFjgH12OvR55ZeKyZianz/lCZ8NcyATblM0EUCVKpx1gv4BcPfbprcycgnyLbw R+SoPl0wJDWKGqwuCFYkLMaT4XsLYnJv+6C/aQQ8CJjovAVUzaeDXwlJzPP3hH+N iIZp3b5tULHK/c/AykjoRQPq/rVy9ywMvlqmafIeR4+BEJBVYlUGLhum14pnjAQo B/wLCSmxrP7K7E+71ODunUdpts6HsH+GbKqSjBS46BAY/Vw+icq0v5RxaIaa6WCv BEkVEIfcJ/pnlmxMCoQEVu0bjCrIIaTe7EflO4BDhEIrWTxSq19vCVlXB+XgsHUI DWPyCFnAWFG5bZi50PKkrwTOhmcRMRgAjc69DOZ400chbuMAj9PxpomYBEeWvnss N+DLTLL2Yp4Y8/tMJIxjNB2eAbiSKql2EoGIpyjQruDRmg1Bcug5gBY90RjRr204 afoNJYCbtPnd0mY= =hhCg -----END PGP SIGNATURE----- Merge tag 'pci-v7.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Bjorn Helgaas: - Make BAR resize work even for devices where no upstream bridge is visible to the OS, which fixes an amdgpu regression on SolidRun HoneyComb, which doesn't expose Root Ports to the OS (Liz Fong-Jones) - Omit bus properties in dynamic OF nodes when a bridge has no subordinate bus, which fixes early boot hangs caused by NULL pointer dereferences with CONFIG_PCI_DYNAMIC_OF_NODES enabled (Angel J) - Disable enhanced atomics on AMD NBIO 7.7 and 7.11 to avoid silent data corruption on 64-bit DMAs (Mario Limonciello) * tag 'pci-v7.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11 PCI: of_property: Omit bus properties without a subordinate bus PCI: Fix BAR resize for devices on a root bus |
||
|
|
eff8d2791c |
Arm:
- Invalidate the ITS translation cache when the guest changes the
base address of the ITS tables (Fuad Tabba)
- Skip saving ITS devices with device IDs that are out-of-bounds
rather than failing the entire ITS save ioctl (Fuad Tabba)
- Close race between VM teardown and invalidations of nested MMUs
when handling MMU operations that are allowed to block
(Lorenzo Stoakes)
- Various fixes for the handling of the host's untrusted SVE
configuration in pKVM (Fuad Tabba)
- Make sure that empty SMCCC ranges based at 0 are rejected by the
kvm_smccc_set_filter() (Karl Mehltretter)
- Revoke the host mapping for pKVM's private stack pages, along
with a new sanity check that all mappings in the hyp's private
VA range have been correctly marked as hyp-owned (Fuad Tabba)
- Lifetime fixes for the array of shadow stage-2 MMUs, ensuring that
concurrent vCPU initialization cannot relocate in-use MMUs. Defer
the freeing of shadow stage-2 MMUs to the point that no other users
(e.g. MMU notifier) could reference them (Marc Zyngier)
- Drop useless WARN when rejecting an unsupported ioctl for pKVM
(Fuad Tabba)
- Fix the steal_time selftest to install correctly-sized mappings for
non-4K hosts (Sebastian Ott)
- Correct mapping of fine-grained trap for GCSPOPX instruction
(Mark Brown)
- Fix KVM_BUG_ON() due to missing handling of DBGBXVR<n> from 32-bit
guests (Karl Mehltretter)
RISC-V:
- Synchronize hrtimer during VCPU teardown.
- Fix the conversion between vsip and hvip values.
- Serialize IMSIC attributes with vCPU migration.
- Release unused page after MMU invalidation.
- Propagate interrupted G-stage faults to KVM user-space as EINTR.
- Fix nested acceleration hfence entry update order.
- Fix sdata leak and stale snapshot_addr in snapshot_set_shmem.
- Preserve firmware counter value across PMU counter stop/start.
- Report PMU snapshot write failure to the guest.
- Fix perf-backed counter accounting across PMU stop and read.
- Correctly propagate error of a hart status SBI call.
s390:
- Ensure that accesses through kvm_arch_set_irq_inatomic mark as dirty
the pages that contain indicator and summary bits.
- Fix compile warning for kvm_s390_update_cmma_dirty().
- Fix incorrect propagation of ENOENT from _gaccess_shadow_fault() to
userspace.
- Move s390_kvm_mmu_commit_memory_region() into
s390_kvm_mmu_prepare_memory_region() so that it can fail instead of WARN.
- Add missing srcu in kvm_s390_set_irq_state().
- Fix potential races in storage functions.
- Fix race in _destroy_pages_crste().
- Fix issues in the handling of KVM interrupt and page resources, when a
queue that is assigned to a mediated device (mdev) is removed from the
host's AP configuration.
- Fix loop condition in uv_find_secrets.
- Prevent potential out-of-bounds read.
x86:
- Fix a brown paper bag bug where KVM would incorrectly treat Intel PMU MSRs
as valid on AMD.
- Fix a regression in the hardware disable selftest where it checked the wrong
macro when detecting glibc support (breaks at least musl).
- Never clear KVM_REQ_VM_DEAD so that dead VMs stay dead, which is especially
important for KVM_BUG_ON() flows, which often guard more dangerous bugs.
- Re-pend GET_NESTED_STATE_PAGES if getting the pages fails, to fix a bug
where KVM would let userspace run a broken setup with stale vmcs12 pages.
- Fix a class of bugs where KVM would fail to fill kvm_run exit fields if
getting nested pages failed.
- Treat reserved entries in the memory attributes xarray as "no attributes",
to fix false positives when checking for mixed attributes.
- Fix memcg accounting for the memory attributes xarray (the xarray library
subtly requires the xarray to be configured for accounting upfront; the gfp
flags taken at runtime are used only rarely).
- Don't pre-reserve xarray entries when storing empty attributes, as storing
NULL must not require memory allocation (KVM and other subsystems heavily
rely on this behavior).
- Fix a memory leak and a cache maintenance issue related to doing intra-host
migration on an SEV guest.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmq3Ta0UHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroMcygf/Z8GovgUACbWs/PSgVxZr5++MsbnM
/N+vUP0VhsBxWCt191fBmKSBMNyTL734CKe0fkmisIAIPxf63uA3lttfMshNXKct
VJ3TQkbA7qiSEGf2Um1dp4k6egqDDbTS1a4NF7CM7AEL4Wm3YDfqv2h4rZicEBsd
Spy4yV8sKoiEHMnduhF2m5r0cWkrj194e2dolJy0p1WiNeEykf/nMTmNq5JWusBh
TDDzZf1p2BianOmQ6+fkzAfWDSIdv0OPmoH7iqvQ/xhvm4dLWq2oeOz5Q2/uWAp0
BqU4Z5zBrGRUWyXM0cDZEqBfmNH4v7oR9PfLgvD4qpMoqONuMj1+mIO68A==
=XtLD
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"Arm:
- Invalidate the ITS translation cache when the guest changes the
base address of the ITS tables (Fuad Tabba)
- Skip saving ITS devices with device IDs that are out-of-bounds
rather than failing the entire ITS save ioctl (Fuad Tabba)
- Close race between VM teardown and invalidations of nested MMUs
when handling MMU operations that are allowed to block (Lorenzo
Stoakes)
- Various fixes for the handling of the host's untrusted SVE
configuration in pKVM (Fuad Tabba)
- Make sure that empty SMCCC ranges based at 0 are rejected by the
kvm_smccc_set_filter() (Karl Mehltretter)
- Revoke the host mapping for pKVM's private stack pages, along with
a new sanity check that all mappings in the hyp's private VA range
have been correctly marked as hyp-owned (Fuad Tabba)
- Lifetime fixes for the array of shadow stage-2 MMUs, ensuring that
concurrent vCPU initialization cannot relocate in-use MMUs. Defer
the freeing of shadow stage-2 MMUs to the point that no other users
(e.g. MMU notifier) could reference them (Marc Zyngier)
- Drop useless WARN when rejecting an unsupported ioctl for pKVM
(Fuad Tabba)
- Fix the steal_time selftest to install correctly-sized mappings for
non-4K hosts (Sebastian Ott)
- Correct mapping of fine-grained trap for GCSPOPX instruction (Mark
Brown)
- Fix KVM_BUG_ON() due to missing handling of DBGBXVR<n> from 32-bit
guests (Karl Mehltretter)
RISC-V:
- Synchronize hrtimer during VCPU teardown
- Fix the conversion between vsip and hvip values
- Serialize IMSIC attributes with vCPU migration
- Release unused page after MMU invalidation
- Propagate interrupted G-stage faults to KVM user-space as EINTR
- Fix nested acceleration hfence entry update order
- Fix sdata leak and stale snapshot_addr in snapshot_set_shmem
- Preserve firmware counter value across PMU counter stop/start
- Report PMU snapshot write failure to the guest
- Fix perf-backed counter accounting across PMU stop and read
- Correctly propagate error of a hart status SBI call
s390:
- Ensure that accesses through kvm_arch_set_irq_inatomic mark as
dirty the pages that contain indicator and summary bits
- Fix compile warning for kvm_s390_update_cmma_dirty()
- Fix incorrect propagation of ENOENT from _gaccess_shadow_fault() to
userspace
- Move s390_kvm_mmu_commit_memory_region() into
s390_kvm_mmu_prepare_memory_region() so that it can fail instead of
WARN
- Add missing srcu in kvm_s390_set_irq_state()
- Fix potential races in storage functions
- Fix race in _destroy_pages_crste()
- Fix issues in the handling of KVM interrupt and page resources,
when a queue that is assigned to a mediated device (mdev) is
removed from the host's AP configuration
- Fix loop condition in uv_find_secrets
- Prevent potential out-of-bounds read
x86:
- Fix a brown paper bag bug where KVM would incorrectly treat Intel
PMU MSRs as valid on AMD
- Fix a regression in the hardware disable selftest where it checked
the wrong macro when detecting glibc support (breaks at least musl)
- Never clear KVM_REQ_VM_DEAD so that dead VMs stay dead, which is
especially important for KVM_BUG_ON() flows, which often guard more
dangerous bugs
- Re-pend GET_NESTED_STATE_PAGES if getting the pages fails, to fix a
bug where KVM would let userspace run a broken setup with stale
vmcs12 pages
- Fix a class of bugs where KVM would fail to fill kvm_run exit
fields if getting nested pages failed
- Treat reserved entries in the memory attributes xarray as "no
attributes", to fix false positives when checking for mixed
attributes
- Fix memcg accounting for the memory attributes xarray (the xarray
library subtly requires the xarray to be configured for accounting
upfront; the gfp flags taken at runtime are used only rarely)
- Don't pre-reserve xarray entries when storing empty attributes, as
storing NULL must not require memory allocation (KVM and other
subsystems heavily rely on this behavior)
- Fix a memory leak and a cache maintenance issue related to doing
intra-host migration on an SEV guest"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (54 commits)
KVM: SEV: Do cache maintenance on the source VM during intra-host migration
KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV
KVM: Don't pre-reserve xarray entries when storing empty/NULL attributes
KVM: Ensure memory attributes xarray nodes are accounted to the caller's memcg
KVM: Don't treat reserved xarray entries as having memory attributes
KVM: x86: Fill kvm_run exit fields in common get_nested_state_pages() error paths
KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails
KVM: arm64: Fix AArch32 DBGBXVR<n> handling
KVM: arm64: Fix FGT mapping for HFGITR_EL2.nGCSEPP
KVM: selftests: fix steal_time for arm64 with host page size > 4K
KVM: arm64: Don't WARN on an unknown VM ioctl in protected mode
KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction
KVM: arm64: nv: Fix life cycle of the nested_mmus array
KVM: arm64: Check every private mapping is hyp-owned at pKVM init
KVM: arm64: Move the private VA allocation cursor to __io_map_next
KVM: arm64: Match hyp text by physical address in fix_host_ownership()
KVM: arm64: Transfer the hyp stack pages out of the host stage-2
KVM: arm64: selftests: Test empty SMCCC filter range at base 0
KVM: arm64: Return -EINVAL for an empty SMCCC filter range at base 0
KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2
...
|
||
|
|
2abb25273c |
KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified
Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the
runtime eVMCS controls (pin, primary, secondary, etc.) are being updated.
If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and
then runs the same L2 with TPR virtualization disabled, KVM will fail to
refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR
virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or
L1 by proxy) read and write L0's TPR.
Fixes:
|
||
|
|
9e06bbb9ad |
KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted
Use the MSR permission bitmap of the active VMCB instead of assuming that
KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02
if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM
needs to merge msprm01 with msrpm12.
Don't bother tracking the virtual address of the bitmap that's being used,
as __va() is cheap on x86, and caching the virtual address would introduce
yet another source of potentially stale information.
Fixes:
|
||
|
|
73392706d0 |
KVM: SVM: Sync guest's PERF_CNTR_GLOBAL_CTL from h/w only on successful VMRUN
Don't (re)read PERF_CNTR_GLOBAL_CTL from hardware on a failed VMRUN, as the purpose of the read is to synchronize KVM's cache with any writes done by the guest, and the guest can't possibly have modified the MSR if it never got a chance to run. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260904170642.3291466-5-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
||
|
|
64c5b15af7 |
KVM: SVM: Don't mark ASID fields as dirty when setting control.tlb_ctl
Don't mark the ASID as dirty in the VMCB when requesting a TLB flush via
control.tlb_ctl. Per "15.15.3 VMCB Clean Field" of the July 2026, Revision
3.45 version of the APM:
The following are explicitly not cached and not represented by Clean bits:
* TLB_Control
Fixes:
|
||
|
|
e27fc915c8 |
KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded
Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD: there's no explicit architectural guarantee about the behavior in the presence of VMRUN failures. So the best thing to do would be to assume that if VMRUN fails, the actions requested in the control fields may not have been performed. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260904170642.3291466-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
||
|
|
60d93c2785 |
KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN
Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN,
as empirical testing shows that the CPU performs the requested TLB flush if
and only if VMRUN is successful, i.e. clearing TLB control on a failed
VMRUN effectively drops a TLB flush.
Explicitly track the need to flush all ASIDs on a per-CPU basis, as the
ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus,
this also obviates the need to avoid clobbering FLUSH_ALL_ASID with
TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid().
Deliberately don't bother saving/restoring the "old" tlb_ctl on failure,
in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from
after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If
VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next
successful run of the VMCB *may* unnecessarily flush all ASIDs, which
strictly speaking could result in noisy neighbor issues. However, the
fact that new_asid() is already guest-triggerable, because of KVM's flawed
behavior of clearing the ASID on emulated INIT, means that a guest can
already trigger a flush of all ASIDs at roughly the same rate. And once
KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID
to each vCPU, this flaw goes away.
Fixes:
|
||
|
|
b6249c1d56 |
KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy
When walking shadow page tables, immediately terminate the walk if the root
is a "dummy" root, i.e. a root whose top-level page table is backed by the
zero page, but otherwise doesn't exist. If memslot creation races with a
stage-2 page fault (EPT violation or #NPF) from L2, then if the stars align,
KVM will attempt to walk shadow page tables using the zero page and hit a
NULL pointer deref.
BUG: kernel NULL pointer dereference, address: 0000000000000021
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP
CPU: 30 UID: 1000 PID: 941 Comm: qemu Not tainted 7.2.0-rc2-1b731e5ded48-next-vm #1741 PREEMPTLAZY
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:__kvm_mmu_invalidate_addr+0xea/0x210 [kvm]
Call Trace:
<TASK>
kvm_mmu_invalidate_addr+0x92/0xe0 [kvm]
__kvm_inject_emulated_page_fault+0x67/0x80 [kvm]
ept_page_fault+0x160/0x850 [kvm]
kvm_mmu_do_page_fault+0x102/0x1f0 [kvm]
kvm_mmu_page_fault+0x8e/0x6b0 [kvm]
vmx_handle_exit+0x163/0x640 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x960/0x2120 [kvm]
kvm_vcpu_ioctl+0x2c7/0x970 [kvm]
__x64_sys_ioctl+0x90/0xd0
do_syscall_64+0x67/0x5f0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f606d0b53bb
Opportunistically harden the shadow walks against fully invalid roots, but
WARN, as all callers are expected/required to pre-check for a valid root.
Don't WARN in the dummy root case as the whole point of using a dummy root
is to provide a root that's valid enough to enter the guest, i.e. it should
Just Work for all flows except those that *need* to know about dummy roots.
Alternatively, KVM could allocate a dedicated page and associated shadow
page structure for the dummy root, which is very tempting as it such an
approach should be more resilient against unexpected behavior. But that
would be a much larger and thus riskier change than simply terminating
walks of dummy roots.
Fixes:
|
||
|
|
8264c0d73f |
KVM: Reject attempts to lock all vCPUs if vCPU creation is in-progress
Reject locking of all vCPUs if vCPU creation is in-progress, i.e. if the number of "created" vCPUs doesn't match the number of "onlined" vCPUs. It's simply not possible to guarantee that KVM has truly locked all vCPUs if one or more vCPUs are actively being created. Holding kvm->lock does prevent in-flight vCPUs from being fully onlined, but it's infeasible for common KVM to know whether or not that provides sufficient protection. In practice, this is likely a minor bug fix for the ARM and RISC-V usage of kvm_trylock_all_vcpus(), and a glorified nop for everything else. E.g. ARM's kvm_timer_vcpu_init() can race kvm_vm_ioctl_set_counter_offset() with respect to observing KVM_ARCH_FLAG_VM_COUNTER_OFFSET. Opportunistically drop x86's existing manual checks on vCPU creation being in-progress as all of x86's checks immediately precede or follow locking of all vCPUs. Leave arm64 and RISC-V alone for the moment, as their checks aren't as obviously redundant/equivalent. Signed-off-by: Sean Christopherson <seanjc@google.com> Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net> Tested-by: Naveen N Rao (AMD) <naveen@kernel.org> Message-ID: <20260921174445.911676-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
||
|
|
c2f24f140c |
KVM fixes for 7.3-rcN
- Fix a brown paper bag bug where KVM would incorrectly treat Intel PMU MSRs
as valid on AMD.
- Fix a regression in the hardware disable selftest where it checked the wrong
macro when detecting glibc support (breaks at least musl).
- Never clear KVM_REQ_VM_DEAD so that dead VMs stay dead, which is especially
important for KVM_BUG_ON() flows, which often guard more dangerous bugs.
- Re-pend GET_NESTED_STATE_PAGES if getting the pages fails, to fix a bug
where KVM would let userspace run a broken setup with stale vmcs12 pages.
- Fix a class of bugs where KVM would fail to fill kvm_run exit fields if
getting nested pages failed.
- Treat reserved entries in the memory attributes xarray as "no attributes",
to fix false positives when checking for mixed attributes.
- Fix memcg accounting for the memory attributes xarray (the xarray library
subtly requires the xarray to be configured for accounting upfront; the gfp
flags taken at runtime are used only rarely).
- Don't pre-reserve xarray entries when storing empty attributes, as storing
NULL must not require memory allocation (KVM and other subsystems heavily
rely on this behavior).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmq3A78ACgkQOlYIJqCj
N/1uVA//TVDznH49htPNV4dh7vfiE8oF9ka4e9KTPA2eMdDeNVInNXBz0ZbJCdNN
Hm7iZZfk8yx0JCCGXdp8EoYg66iwulBr0KZXRP2U2LoyiRELA1VtGGOLUVP3PXjF
hElXD56+RrkJJSucINlFU7kSfl2hY/Jbaq87HVBLpXp8iY3stBbLdgMT1ReLdorO
s9i2uJRqHKjtSG330qDYEG1TtRAdUehgRbxbbJVuOEYtU37tCvX6ai8dEjZAvxYo
1VZOD05ITo12HUXPiZjIMoNTujQnZKmGYlBYczWlfOmkY/tN6SV8M41srV3ZcK0k
XGOQM6tOzbVTWaSH/pW1krklnOFAbnL6QzHzb3enHZfUN8AikHPDyfsJWzt/s0f/
ATTQk03OYL4fJMQSQ778EI6S4PcOzY9HiBxDXM5ySpUv1uyXw8ZFsQSdH/TYTMhi
Dce42r5rlGa1vAKHwI1Xya2su3REhWzxYxGpUOg/PtRRqWvL2RMrHArzEd6zu+Ti
jPinuQuXYcT1FTCa5S39NWhU4gWpjw8Pvs9VuUYSCDYxZCaqQ2YheYgsAcgPqgfE
hS43XVmmOB/tXGsvu+/YuEfbzNV/mHOuJBcjBnnsBP3d6EFB02FPKg4/LYiXujYo
OocUbSB7bKd87W3B+Ys3QmgOtZh4qX/aLYusa2vQ4Dp9ujXqcWs=
=LG0B
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-fixes-7.3-rc5' of https://github.com/kvm-x86/linux into HEAD
KVM fixes for 7.3-rcN
- Fix a brown paper bag bug where KVM would incorrectly treat Intel PMU MSRs
as valid on AMD.
- Fix a regression in the hardware disable selftest where it checked the wrong
macro when detecting glibc support (breaks at least musl).
- Never clear KVM_REQ_VM_DEAD so that dead VMs stay dead, which is especially
important for KVM_BUG_ON() flows, which often guard more dangerous bugs.
- Re-pend GET_NESTED_STATE_PAGES if getting the pages fails, to fix a bug
where KVM would let userspace run a broken setup with stale vmcs12 pages.
- Fix a class of bugs where KVM would fail to fill kvm_run exit fields if
getting nested pages failed.
- Treat reserved entries in the memory attributes xarray as "no attributes",
to fix false positives when checking for mixed attributes.
- Fix memcg accounting for the memory attributes xarray (the xarray library
subtly requires the xarray to be configured for accounting upfront; the gfp
flags taken at runtime are used only rarely).
- Don't pre-reserve xarray entries when storing empty attributes, as storing
NULL must not require memory allocation (KVM and other subsystems heavily
rely on this behavior).
|
||
|
|
93de2a6a4b |
KVM: SEV: Do cache maintenance on the source VM during intra-host migration
Manually perform cache maintenance on the source VM during intra-host
migration to ensure no stale data is left in CPU caches after the VM is
destroyed. Because the source VM is "converted" to a non-SEV VM, KVM's
memory reclaim flows won't trigger cache maintenance, e.g. when all guest
memory is reclaimed in response to detaching from the mmu_notifier.
Note, relying on the destination VM to do cache maintenance isn't an option
as KVM doesn't require identical guest memory configurations, i.e. the
source VM may have access to memory that the destination VM does not.
Enforcing equivalent memory configurations is infeasible, as it would
require a *deep* comparison of memslots, e.g. to verify that not only are
the memslot identical, but what the memslots point at is also identical.
Fixes:
|
||
|
|
12c1f6e03f |
KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV
Unconditionally free SEV's "have run CPUs" cpumask in the VM destroy path,
i.e. even for what appear to be non-SEV VMs, as an SEV VM becomes a non-SEV
VM if its state is intra-host migrated. Alternatively, the mask could be
freed in sev_migrate_from() when "converting" the source VM, but that gets
annoying because ideally KVM would nullify the mask to guard against UAF,
and nullifying the mask would need be conditioned on CPUMASK_OFFSTACK=y.
Freeing the mask during sev_migrate_from() is also not robust against other
KVM bugs, though that's kind of a moot point since any such bugs would show
up even if sev->active is never set. I.e. KVM must get that side of things
correct. But, that's not a great reason to add more code just to make
things marginally less robust.
Fixes:
|
||
|
|
4fde448225 |
x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11
Multiple users report data corruption during 64-bit DMA transfers on systems with AMD NBIO 7.7 and 7.11 controllers. This occurs when BIOS enables AMD "enhanced atomic operations" on PCIe Root Ports. When enhanced atomics are enabled, any 64-bit DMA access may be corrupted. Disable enhanced atomics using SMN for NBIO 7.7 and 7.11 based models. Reported-by: Mikael Etienne <mikael1022bzh@gmail.com> Closes: https://lore.kernel.org/178789300872.392066.15963676631650361573@gmail.com/ Reported-by: Arthur Husband <artmoty@gmail.com> Closes: https://lore.kernel.org/20260406222335.379935-1-artmoty@gmail.com/ Reported-by: Alvin Lim <alvinwylim@gmail.com> Closes: https://lore.kernel.org/20260621100844.1224301-1-alvinwylim@gmail.com/ Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> [bhelgaas: commit log, s/IOVA/DMA/ in comment] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Cc: David Laight <david.laight.linux@gmail.com> Cc: John Smith <imjohnsmith4000@gmail.com> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Niklas Cassel <cassel@kernel.org> Cc: Roland Waltersson <roland.waltersson@netinsight.net> Link: https://patch.msgid.link/20260908190600.226485-2-mario.limonciello@amd.com |
||
|
|
b8d1d5b63a |
x86/mce: Fix hardware debug register corruption on task migration
In exc_machine_check_user(), local_db_save() and local_db_restore() are
invoked in the outer entry stubs (DEFINE_IDTENTRY_MCE_USER,
DEFINE_FREDENTRY_MCE, and DEFINE_IDTENTRY_RAW), surrounding
exc_machine_check_user().
However, exc_machine_check_user() calls irqentry_exit_to_user_mode(), which
handles pending thread work and may schedule() if TIF_NEED_RESCHED is set. If
the task migrates to another CPU during schedule(), local_db_restore() runs on
the new CPU with the dr7 state saved from the old CPU. This corrupts the new
CPU's DR7 hardware debug register and leaves the old CPU's DR7 disabled. In
short, local_db_save() and local_db_restore() pair must be run on the same
CPU.
To fix this, move local_db_save() and local_db_restore() inside
exc_machine_check_user() and exc_machine_check_kernel(). In
exc_machine_check_user(), DR7 is saved and restored strictly around
do_machine_check() to avoid schedule() during migration. In
exc_machine_check_kernel(), local_db_save() is called at the entry point to
prevent early memory accesses from triggering nested #DB exceptions, and
restored on all exits.
Fixes:
|
||
|
|
24b620729e |
perf/core: Fill branch entries with a single assignment
perf_clear_branch_entry_bitfields() clears the bitfields of struct perf_branch_entry one by one and leaves from/to alone, since callers overwrite those straight away. The list has to be kept in sync with the struct by hand and has already fallen behind: new_type and priv were added to perf_branch_entry and never added here. Only BRBE writes those two, and neither for every record. brbe_set_perf_entry_type() leaves new_type alone for a branch type it does not recognise, and priv is not set for source-only records. arm_pmuv3.c allocates the per-CPU branch stack with kmalloc(), so such a record reaches userspace with whatever the slot held: uninitialised kmalloc() data on the first pass over the buffer, the previous record's values after that. Nothing under arch/x86/events/ writes either field, so only arm64 is affected. Assign the whole entry at each site instead. Everything not named is then zero, and there is no list to keep in sync. The bitfields add up to exactly 64 bits, so the struct has no padding to leave undefined. perf_clear_branch_entry_bitfields() has no callers left, so remove it. perf_entry_from_brbe_regset() assigns an empty literal instead, since it fills from/to conditionally. PERF_BR_SPEC_NA is 0, so dropping the explicit spec assignment changes nothing. Fixes: |
||
|
|
c1214f293d |
KVM: x86: Fill kvm_run exit fields in common get_nested_state_pages() error paths
Fill kvm_run with "internal error, emulation" in the common error handling paths for getting nested state pages, as requiring each check to manually fill kvm_run is error prone and requires a non-trivial amount of copy+paste. Specifically, both SVM and VMX fail to fill kvm_run if load_pdptrs() fails, and SVM fails to fill kvm_run if kvm_hv_verify_vp_assist() fails. If those flows fail, the *best* case scenario is that KVM will exit to userspace with KVM_EXIT_UNKNOWN. The worst case scenario is that KVM exits with a stale exit_reason and confuses userspace. Note, SVM never exits to userspace if something goes sideways when dealing with vmcb12 assets while emulating VMRUN, i.e. lack of SVM-specific code is not a bug. Fixes: |
||
|
|
10180a2775 |
KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails
Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page. Note, both SVM and VMX (as of commit |
||
|
|
d4d9ccbad5 |
perf/x86/intel: Rename NVL offcore_rsp attribute to offmodule_rsp
NVL introduces Offmodule Response events in place of the legacy Offcore Response events, but it still exposes the inherited offcore_rsp PMU attribute for programming the corresponding MSR data. Rename the NVL PMU attribute to offmodule_rsp so the sysfs interface matches the underlying event name and avoids user & tooling confusion. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260917015234.981153-13-dapeng1.mi@linux.intel.com |
||
|
|
0102c8c7fd |
perf/x86/intel: Rename DMR offcore_rsp attribute to offmodule_rsp
DMR introduces Offmodule Response events in place of the legacy Offcore Response events, but it still exposes the inherited offcore_rsp PMU attribute for programming the corresponding MSR data. Rename the DMR PMU attribute to offmodule_rsp so the sysfs interface matches the underlying event name and avoids user & tooling confusion. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260917015234.981153-12-dapeng1.mi@linux.intel.com |
||
|
|
ff1621adfd |
perf/x86/intel: Fix precise OMR event scheduling for DMR/NVL
The latest perfmon event database introduces below precise OMR event support for DMR/NVL: - MEM_LOAD_L2_MISS_RETIRED.* (event 0xd6) - MEM_STORE_L2_MISS_RETIRED.* (event 0x4f) These events use the same OMR MSRs as the existing OMR events, but they are not listed in intel_pnc_extra_regs[]. As a result, perf cannot assign the required OMR extra registers when scheduling them. Add the new precise OMR events to intel_pnc_extra_regs[] so they can be scheduled with the correct OMR MSRs. MEM_LOAD_L2_MISS_RETIRED.* remains limited to GP counters 0-3, while MEM_STORE_L2_MISS_RETIRED.* is available on all GP counters. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260917015234.981153-11-dapeng1.mi@linux.intel.com |
||
|
|
04a7ef3b7a |
perf/x86/intel: Constrain Panther Cove UOPS_DISPATCHED events to PMCs 0-3
Per the latest Panther Cove event definitions, the following events are
only supported on PMCs 0-3:
- UOPS_DISPATCHED.INT_EU_ALL (0x1b2)
- UOPS_DISPATCHED.ALU (0x2b2)
Add explicit event constraints for these two events so scheduling does
not place them on unsupported counters.
Fixes:
|