Commit Graph

52664 Commits

Author SHA1 Message Date
Linus Torvalds
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
2026-10-15 08:12:47 -07:00
Linus Torvalds
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()
2026-10-15 08:06:26 -07:00
Amirmohammad Eftekhar
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: 72e9cbdb43 ("KVM: nVMX: fix SMI injection in guest mode")
Fixes: 8fcc4b5923 ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
Cc: stable@vger.kernel.org
Signed-off-by: Amirmohammad Eftekhar <amirmohammadeftekhar@gmail.com>
[sean: write changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://patch.msgid.link/20261001214356.3825100-2-seanjc@google.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-10-14 16:42:40 +02:00
EJ Campbell
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>
2026-10-14 16:10:15 +02:00
Linus Torvalds
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 b41f2ca6c0 ("KVM: VMX:
   Fix stale PID-pointer table entry left after vCPU free").
 
 - Use set_page_dirty_lock() instead of set_page_dirty() when marking a page
   dirty after writing back SNP firmware's desired CPUID state to userspace.
   Using set_page_dirty() is unsafe if the page/folio isn't locked (as pointed
   out by its function comment's big DANGER warning, which no one reads given
   the number of bugs of this exact nature).
 
 - When checking for an MMIO generation match, use the memslots for the current
   vCPU context (non-SMM vs. SMM), as a misbehaving guest can coerce KVM into
   incorrectly identifying a write as MMIO in order to bypass KVM's
   write-tracking.
 -----BEGIN PGP SIGNATURE-----
 
 iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmrNF30UHHBib256aW5p
 QHJlZGhhdC5jb20ACgkQv/vSX3jHroP+hQf/YEYOwFlxcG8vykALvjqseI/wJRXX
 lvJTrmu78az8mioeFNofc677Oyrbt52bZQOacVX+/csu0SvXfqpPZJ7A85eEjtax
 6deQoqa7Ktee2fjCpsA3hhOpixvwSidCuDf2UgZaV0XYbWoKJVt2KD0SjRUntxOp
 saGCspDgImIgZW1eVW3HPF8w4w5XpUGJvQysZcnoNJUMmRdUKsiP596Ds/VM1gyw
 hbYmG8yzle96mYFq12qGmUMrLh5HanYEr0vqNxcDcg/tc23xb5fHKuZS+RlhhtHO
 phc7+UnRAJWku9Xh+5EYHFwFW2umPmA57oxnBDIjmxxvMWrTv6h1z63MXg==
 =GByw
 -----END PGP SIGNATURE-----

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm fixes from Paolo Bonzini:
 "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
     b41f2ca6c0 ("KVM: VMX: Fix stale PID-pointer table entry left
     after vCPU free").

   - Use set_page_dirty_lock() instead of set_page_dirty() when marking
     a page dirty after writing back SNP firmware's desired CPUID state
     to userspace.

     Using set_page_dirty() is unsafe if the page/folio isn't locked (as
     pointed out by its function comment's big DANGER warning, which no
     one reads given the number of bugs of this exact nature).

   - When checking for an MMIO generation match, use the memslots for
     the current vCPU context (non-SMM vs. SMM), as a misbehaving guest
     can coerce KVM into incorrectly identifying a write as MMIO in
     order to bypass KVM's write-tracking"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes
  KVM: x86: Use active memslots for the per-vCPU MMIO cache
  KVM: SEV: Fix page dirtying in sev_gmem_post_populate()
  KVM: SVM: Clear AVIC Physical ID table entry if vCPU creation fails
  KVM: SVM: Use "is AVIC-addressable" helper to sanity check load()/put()
  KVM: SVM: Add paranoid helper for checking if vCPU is AVIC-addressable
2026-10-13 16:41:23 -07:00
Paolo Bonzini
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 687ee95c1b ("KVM:
nSVM: enable GMET for guests"), even though SHSTK was available to guests
since Linux 6.18.  However, this is not because bit 1 of MISC_CTL (GMET)
somehow enables reporting the SS bit; rather, it's simply that Hyper-V
never uses CET unless GMET is also present.  The WARN is reproducible
even with gmet=0, with some hacking of kvm-unit-tests's cet.c testcase
to ensure that the first access to the shadow stack triggers a page fault.

Reported-by: SimonP <simonp.git@mailbox.org>
Fixes: 8db428fd52 ("KVM: SVM: Enable shadow stack virtualization for SVM")
Cc: stable@vger.kernel.org
Reviewed-by: Sean Christopherson <seanjc@google.com>
Closes: https://lore.kernel.org/all/asUqYEisPp9MJ8mQ@rika.bernkas.tel
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-10-12 19:22:54 +02:00
Paolo Bonzini
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 b41f2ca6c0 ("KVM: VMX:
    Fix stale PID-pointer table entry left after vCPU free").
 
  - Use set_page_dirty_lock() instead of set_page_dirty() when marking a page
    dirty after writing back SNP firmware's desired CPUID state to userspace.
    Using set_page_dirty() is unsafe if the page/folio isn't locked (as pointed
    out by its function comment's big DANGER warning, which no one reads given
    the number of bugs of this exact nature).
 
  - When checking for an MMIO generation match, use the memslots for the current
    vCPU context (non-SMM vs. SMM), as a misbehaving guest can coerce KVM into
    incorrectly identifying a write as MMIO in order to bypass KVM's
    write-tracking.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmq/3aEACgkQOlYIJqCj
 N/0Qrg/+L64WbZWMUkLmW+8p3mDfk4gxn1HknzAN6EUQaHx+Qj4xjV++ydGDlBYt
 jfPFCpnotz0PihnWVCTzg0UsVLg4+8Ab2MIV1mrAxuurZNBSxAwESEpN6B0Glz8T
 0b7c5JC+4JuEVzaL+IYLjx3uV0Qo91cJiTF+N+aikLV0vESnLwc+s1pvZeIw+6Jf
 iV+tirgRAHhVXdcbAavoDyqqMCb7sGIkXB4rr6WYjmF90nFnE7xdtLDSvdJMsYxc
 HljehKhxuCujsZsgAbeRLx3Z1kz17cohS559sVPQgOTbmTv2CBE6jRRsodHVPRA7
 OfGYV40UMpQjyHDl0e19eFLdeSY9sTDa+GZkKhR2P7zo2f7Kwuhl9/hu5Jf8aFx0
 50vjpXZh7LSA5x3ftwOiKkZxfVCJOoB/YMSDw2WophNmsUHv1v932Y++57TdD9HH
 nvZsqyxZ16kZRMBESvkyeV50uvlBuZEMKyF2bq0+3UaodpcvemYlIXvFGEbZVxL9
 Ai424rwD1qbQhX6F8y94T+M8ZOLkd+1oecEWno3+MiqwXo43h2X2RmoNLk95fybi
 RkD5fbwGXqgW9pFt5awqqR2HPprrpCQvD22dU3QrWpzg0B042FhfcBe4lWinbk9x
 WssNn6javiuoHiuO9dZ5v4llI0H7wysyZuwgUV4joU15THfIBGQ=
 =EQ6H
 -----END PGP SIGNATURE-----

Merge tag 'kvm-x86-fixes-7.3-rc6' of https://github.com/kvm-x86/linux into HEAD

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 b41f2ca6c0 ("KVM: VMX:
   Fix stale PID-pointer table entry left after vCPU free").

 - Use set_page_dirty_lock() instead of set_page_dirty() when marking a page
   dirty after writing back SNP firmware's desired CPUID state to userspace.
   Using set_page_dirty() is unsafe if the page/folio isn't locked (as pointed
   out by its function comment's big DANGER warning, which no one reads given
   the number of bugs of this exact nature).

 - When checking for an MMIO generation match, use the memslots for the current
   vCPU context (non-SMM vs. SMM), as a misbehaving guest can coerce KVM into
   incorrectly identifying a write as MMIO in order to bypass KVM's
   write-tracking.
2026-10-09 17:49:26 +02:00
Borislav Petkov (AMD)
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: 82378c6c2f ("x86/mm: Use INVLPGB for kernel TLB flushes")
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Tested-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Tested-by: Rik van Riel <riel@surriel.com>
Cc: stable@kernel.org
Link: https://patch.msgid.link/20261002211617.1001617-1-bp@kernel.org
2026-10-05 10:29:08 -07:00
Linus Torvalds
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
2026-10-04 08:59:22 -07:00
Linus Torvalds
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
2026-10-02 12:59:32 -07:00
Linus Torvalds
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
2026-10-02 11:28:45 -07:00
Nathan Chancellor
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: 90cebef141 [1]
Link: https://gcc.gnu.org/onlinedocs/gcc-16.2.0/gcc/Standards.html#index-ffreestanding [2]
Link: b28eeb28be [3]
Link: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline-stringops [4]
Closes: https://github.com/ClangBuiltLinux/linux/issues/2183
Cc: stable@vger.kernel.org # v6.12+
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2026-10-02 12:12:13 +02:00
Linus Torvalds
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
2026-10-01 11:04:27 -07:00
Linus Torvalds
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 97d65b544f ("KVM: Check for duplicate vcpu_id
   as early as possible", from the 7.3 merge window), and does not waste
   2K per VM, hence its inclusion here.
 -----BEGIN PGP SIGNATURE-----
 
 iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmq+lW0UHHBib256aW5p
 QHJlZGhhdC5jb20ACgkQv/vSX3jHroPUbAf/Vap8HMmHlfQ0/A+25CZtJjWNOuNM
 Zj3YMFLGjiqTHTVjWafWCpvS2kWdV/MyTcgFxEKyx/QJ7cxofLAHCtak5TYoUyJ7
 oUQaHf2eK6VdtA1yz7yBf0zQSpKZhOoF3Ze2kQCUaR1ZEHm3apcFeh7jnjFammdx
 YpeHm1ERKJW9KQNc4KXH9dIx8IGjOW5C6hAcxgZKUeTy+5oz7FMOqPQc/wNowOG5
 ldxzSDa+BoHZ/okOkeBWgTfYFPH0MU3CO/ZX9+eJ+HIIEZ+XkVzo3h8KBpmWPTqj
 dAksp8oZeg9B9XLzxklCAnpJaoNQHhQlQJAwJMivwwNwT99drizphQY7Bw==
 =1X9h
 -----END PGP SIGNATURE-----

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm fixes from Paolo Bonzini:
 "The most intrusive change is reverting a commit from 7.3-rc1 that made
  struct kvm a bit too large, and fixing the same issue otherwise.

  There are again a lot of selftests lines; the sheer number of commits
  is not small but I don't expect much more for 7.3 due to people
  travelling to Plumbers next week.

  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 97d65b544f ("KVM: Check for duplicate
     vcpu_id as early as possible", from the 7.3 merge window), and does
     not waste 2K per VM, hence its inclusion here"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (29 commits)
  KVM: arm64: Use stage-1 leaf size for VM_PFNMAP
  KVM: arm64: selftests: Check a feature hidden in an ID register is UNDEF
  KVM: arm64: Use the host's HCR_EL2 for non-protected VMs in pKVM
  KVM: arm64: Clear HCR_EL2.RW for 32-bit non-protected vCPUs
  KVM: arm64: Apply the fine-grained UNDEFs without FEAT_FGT
  KVM: arm64: vgic-its: Fix MOVALL handling of source redistributor
  KVM: arm64: vgic: Take a refcount on IRQs referenced by last_lr_irq
  KVM: arm64: vgic: Allow last_lr_irq to be NULL when LRs are not overflowing
  KVM: SEV: Do cache maintenance on the source VM *before* clearing SEV state
  KVM: SEV: Nullify "have run CPUs" mask pointer when freeing it
  KVM: selftests: Extend nested x2APIC test to validate using eVMCS for vmcs12
  KVM: selftests: Extend nested x2APIC test to validate disabling x2APIC virt
  KVM: selftests: Verify that L0's TPR doesn't get clobbered
  KVM: selftests: Run the nested x2APIC with and without APICv being inhibited in L2
  KVM: selftests: Add x2APIC MSR test for inhibiting APICv while nested
  KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified
  KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted
  KVM: SVM: Sync guest's PERF_CNTR_GLOBAL_CTL from h/w only on successful VMRUN
  KVM: SVM: Don't mark ASID fields as dirty when setting control.tlb_ctl
  KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded
  ...
2026-10-01 10:57:19 -07:00
Jinu Kim
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 56f17dd3fb ("kvm: x86: fix stale mmio cache bug") added the
memslot generation to the cache key so that a memslot update could not
leave a stale entry valid.  When commit 699023e239 ("KVM: x86: add SMM
to the MMU role, support SMRAM address space") added the SMM address space,
these helpers were not converted to use the active memslots.

Consequently, an update to the SMM memslots can leave an entry from the old
SMM address space apparently valid after the vCPU returns to the normal
address space.  A guest can then cause an access to valid RAM at the same
GFN to be returned to userspace as KVM_EXIT_MMIO.

Completing that exit through the VMM's RAM address space writes the backing
page without going through KVM's write-tracking path.  If the page backs a
nested EPT table, KVM can continue using shadow translations derived from
the old contents.  The WARN_ON_ONCE() in kvm_mmu_write_protect_fault()
catches this invalid cache and memslot combination.

Use the vCPU's active memslots when caching and validating the entry.
Memslot generations are unique across address spaces, so the generation
also distinguishes the normal and SMM views.  This matches the MMIO SPTE
cache, which already uses kvm_vcpu_memslots().

On an unpatched current-mainline kernel, a regression test that fills the
cache in SMM and updates only the SMM memslots fails the intended RAM write
and triggers the kvm_mmu_write_protect_fault() warning.  With this change,
the same test completes the RAM write without a warning.  The x86/smm_test,
set_memory_region_test, and memslot_modification_stress_test selftests also
pass.

Fixes: 699023e239 ("KVM: x86: add SMM to the MMU role, support SMRAM address space")
Cc: stable@vger.kernel.org
Signed-off-by: Jinu Kim <kimjw04271234@gmail.com>
Link: https://patch.msgid.link/20260807112818.958190-1-kimjw04271234@gmail.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-30 06:40:49 -07:00
Jann Horn
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: 97cd21d57e ("KVM: SEV: Mark source page dirty when writing back CPUID data on failure")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Link: https://patch.msgid.link/20260810-x86-kvm-setpagedirty-v1-1-85f180892d4f@google.com
[sean: tag for stable]
Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-30 06:40:48 -07:00
Naveen N Rao (AMD)
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 b41f2ca6c0 ("KVM: VMX:
Fix stale PID-pointer table entry left after vCPU free").

Though unlikely, it is also possible that svm_vcpu_create() itself fails
after the AVIC Physical ID table entry has been setup if memory
allocation fails in svm_vcpu_alloc_msrpm(). Clear the entry in this path
as well.

Note: this change depends on commit 97d65b544f ("KVM: Check for
duplicate vcpu_id as early as possible"), which ensures that a vCPU with
a duplicate ID is never created. Otherwise, a valid AVIC Physical ID
table entry for an existing vCPU will be cleared.

Fixes: 44a95dae1d ("KVM: x86: Detect and Initialize AVIC support")
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
Tested-by: Atish Patra <atishp@meta.com>
[sean: use avic_is_addressable_vcpu()]
Link: https://patch.msgid.link/20260923155108.1550622-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-30 06:40:47 -07:00
Sean Christopherson
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>
2026-09-30 06:40:47 -07:00
Sean Christopherson
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>
2026-09-30 06:40:46 -07:00
Mohamad Raizudeen
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: e9787deff4 ("crypto: x86/aes-gcm - use the new scatterwalk functions")
Cc: stable@vger.kernel.org
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
Link: https://patch.msgid.link/20260926145903.6061-1-raizudeen.kerneldev@gmail.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-09-29 15:28:42 -07:00
Florent Revest (Anthropic)
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: e21aa34178 ("bpf: Fix fexit trampoline.")
Reported-by: Sechang Lim <rhkrqnwk98@gmail.com>
Suggested-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Florent Revest (Anthropic) <florent.revest@linux.dev>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20260926135605.1217928-3-florent.revest@linux.dev
Closes: https://lore.kernel.org/bpf/20260815071927.147049-1-zirajs7@gmail.com/
2026-09-29 05:54:16 +00:00
Sean Christopherson
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: 93de2a6a4b ("KVM: SEV: Do cache maintenance on the source VM during intra-host migration")
Cc: stable@vger.kernel.org
Reported-by: Sashiko Bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260923165304.1662E1F000FF@smtp.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260928154644.2559454-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-28 17:11:49 -04:00
Sean Christopherson
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: 12c1f6e03f ("KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV")
Cc: stable@vger.kernel.org
Reported-by: Sashiko Bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260923165349.CAAF01F000FF@smtp.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260928154644.2559454-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-28 17:11:49 -04:00
Nick Desaulniers
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
2026-09-28 12:11:19 -07:00
Mikhail Gavrilov
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: d5d8b8662e ("x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF")
Suggested-by: Pedro Falcato <pfalcato@suse.de>
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Link: https://lore.kernel.org/20260916062222.27347-1-mikhail.v.gavrilov@gmail.com
Link: https://lore.kernel.org/all/e11449f0-d9ad-4d1b-ab21-2be7d71fe335@intel.com/ [1]
Link: https://patch.msgid.link/20260923223116.20090-1-mikhail.v.gavrilov@gmail.com
Cc: stable@vger.kernel.org
2026-09-28 08:08:16 -07:00
Laurent Wandrebeck
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: 1317a5e7f7 ("arch/x86: teach arch_get_unmapped_area_vmflags to handle hugetlb mappings")
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Laurent Wandrebeck <l.wandrebeck@quelquesmots.fr>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org # 6.13+
Link: https://patch.msgid.link/20260922085032.46144-1-l.wandrebeck@quelquesmots.fr
2026-09-27 19:46:45 -07:00
Linus Torvalds
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
2026-09-27 08:44:12 -07:00
Linus Torvalds
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
2026-09-27 08:15:58 -07:00
Linus Torvalds
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
2026-09-26 09:59:59 -07:00
Linus Torvalds
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
  ...
2026-09-26 08:26:12 -07:00
Sean Christopherson
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: 502d2bf5f2 ("KVM: nVMX: Implement Enlightened MSR Bitmap feature")
Cc: stable@vger.kernel.org
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-26 02:22:15 -04:00
Sean Christopherson
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: b2ac58f905 ("KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL")
Cc: stable@vger.kernel.org
Reported-by: Stefan Teodorescu <fane@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260826195833.844526-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-26 02:22:12 -04:00
Sean Christopherson
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>
2026-09-26 01:15:43 -04:00
Sean Christopherson
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: 7e8e6eed75 ("KVM: SVM: Move asid to vcpu_svm")
Suggested-by: Yosry Ahmed <yosry@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260904170642.3291466-4-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-26 01:15:43 -04:00
Sean Christopherson
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>
2026-09-26 01:15:43 -04:00
Sean Christopherson
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: 38e5e92fe8 ("KVM: SVM: Implement Flush-By-Asid feature")
Cc: stable@vger.kernel.org
Reported-by: Stefan Teodorescu <fane@google.com>
Suggested-by: Yosry Ahmed <yosry@kernel.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260904170642.3291466-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-26 01:15:43 -04:00
Sean Christopherson
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: 0e3223d8d0 ("KVM: x86/mmu: Use dummy root, backed by zero page, for !visible guest roots")
Reported-by: Gabriel Schneider <gbrls@osec.io>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260925234256.2384816-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-26 01:15:43 -04:00
Sean Christopherson
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>
2026-09-26 00:49:49 -04:00
Paolo Bonzini
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).
2026-09-26 00:40:07 -04:00
Sean Christopherson
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: b56639318b ("KVM: SEV: Add support for SEV intra host migration")
Cc: stable@vger.kernel.org
Reported-by: Stefan Teodorescu <fane@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260923163721.1584779-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-26 00:39:55 -04:00
Sean Christopherson
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: 6f38f8c574 ("KVM: SVM: Flush cache only on CPUs running SEV guest")
Cc: stable@vger.kernel.org
Reported-by: Stefan Teodorescu <fane@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260923163721.1584779-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-09-26 00:39:55 -04:00
Mario Limonciello
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
2026-09-23 13:42:21 -05:00
Masami Hiramatsu (Google)
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: cd840e424f ("x86/entry, mce: Disallow #DB during #MC")
Assisted-by: LLM
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@kernel.org>
Link: https://patch.msgid.link/179005109564.388919.3937970081044095776.stgit@devnote2
2026-09-23 11:28:56 -07:00
Puranjay Mohan
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: b190bc4ac9 ("perf: Extend branch type classification")
Fixes: 5402d25aa5 ("perf: Capture branch privilege information")
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Yifan Wu <wuyifan50@huawei.com>
Link: https://patch.msgid.link/20260810133540.1947118-4-puranjay@kernel.org
2026-09-23 11:48:36 +02:00
Sean Christopherson
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: 0f85722341 ("KVM: nVMX: delay loading of PDPTRs to KVM_REQ_GET_NESTED_STATE_PAGES")
Fixes: 232f75d3b4 ("KVM: nSVM: call nested_svm_load_cr3 on nested state load")
Fixes: 3f4a812edf ("KVM: nSVM: hyper-v: Enable L2 TLB flush")
Cc: stable@vger.kernel.org
Reported-by: Jinwoo Lee <rkskek9254@gmail.com>
Closes: https://lore.kernel.org/all/20260813043932.3214460-1-rkskek9254@gmail.com
Reported-by: Stefan Teodorescu <fane@google.com>
Link: https://patch.msgid.link/20260921211608.1030158-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-22 07:32:50 -07:00
Sean Christopherson
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 11722439fb ("KVM: nVMX: Ensure
KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit") ensure the request
is cleared on VM-Exit (including the "forced" case), i.e. there is no risk
of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request
trying to map the nested pages.

Fixes: 671ddc700f ("KVM: nVMX: Don't leak L1 MMIO regions to L2")
Cc: stable@vger.kernel.org
Reported-by: Jinwoo Lee <rkskek9254@gmail.com>
Closes: https://lore.kernel.org/all/20260813043932.3214460-1-rkskek9254@gmail.com
Reported-by: Stefan Teodorescu <fane@google.com>
Link: https://patch.msgid.link/20260921211608.1030158-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-09-22 07:32:50 -07:00
Dapeng Mi
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
2026-09-22 11:38:17 +02:00
Dapeng Mi
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
2026-09-22 11:37:46 +02:00
Dapeng Mi
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
2026-09-22 11:37:00 +02:00
Dapeng Mi
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: d345b6bb88 ("perf/x86/intel: Add core PMU support for DMR")
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>
Cc: <stable@vger.kernel.org> # v7.0+
Link: https://patch.msgid.link/20260917015234.981153-10-dapeng1.mi@linux.intel.com
2026-09-22 11:35:40 +02:00