linux.git/arch, branch v6.1.154

KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active

2025-09-25T08:58:53+00:00

commit d02e48830e3fce9701265f6c5a58d9bdaf906a76 upstream.

Commit 3bbf3565f48c ("svm: Do not intercept CR8 when enable AVIC")
inhibited pre-VMRUN sync of TPR from LAPIC into VMCB::V_TPR in
sync_lapic_to_cr8() when AVIC is active.

AVIC does automatically sync between these two fields, however it does
so only on explicit guest writes to one of these fields, not on a bare
VMRUN.

This meant that when AVIC is enabled host changes to TPR in the LAPIC
state might not get automatically copied into the V_TPR field of VMCB.

This is especially true when it is the userspace setting LAPIC state via
KVM_SET_LAPIC ioctl() since userspace does not have access to the guest
VMCB.

Practice shows that it is the V_TPR that is actually used by the AVIC to
decide whether to issue pending interrupts to the CPU (not TPR in TASKPRI),
so any leftover value in V_TPR will cause serious interrupt delivery issues
in the guest when AVIC is enabled.

Fix this issue by doing pre-VMRUN TPR sync from LAPIC into VMCB::V_TPR
even when AVIC is enabled.

Fixes: 3bbf3565f48c ("svm: Do not intercept CR8 when enable AVIC")
Cc: stable@vger.kernel.org
Signed-off-by: Maciej S. Szmigiero 
Reviewed-by: Naveen N Rao (AMD) 
Link: https://lore.kernel.org/r/c231be64280b1461e854e1ce3595d70cde3a2e9d.1756139678.git.maciej.szmigiero@oracle.com
[sean: tag for stable@]
Signed-off-by: Sean Christopherson 
Signed-off-by: Greg Kroah-Hartman

LoongArch: Check the return value when creating kobj

2025-09-25T08:58:52+00:00

commit 51adb03e6b865c0c6790f29659ff52d56742de2e upstream.

Add a check for the return value of kobject_create_and_add(), to ensure
that the kobj allocation succeeds for later use.

Cc: stable@vger.kernel.org
Signed-off-by: Tao Cui 
Signed-off-by: Huacai Chen 
Signed-off-by: Greg Kroah-Hartman

LoongArch: Align ACPI structures if ARCH_STRICT_ALIGN enabled

2025-09-25T08:58:52+00:00

commit a9d13433fe17be0e867e51e71a1acd2731fbef8d upstream.

ARCH_STRICT_ALIGN is used for hardware without UAL, now it only control
the -mstrict-align flag. However, ACPI structures are packed by default
so will cause unaligned accesses.

To avoid this, define ACPI_MISALIGNMENT_NOT_SUPPORTED in asm/acenv.h to
align ACPI structures if ARCH_STRICT_ALIGN enabled.

Cc: stable@vger.kernel.org
Reported-by: Binbin Zhou 
Suggested-by: Xi Ruoyao 
Suggested-by: Jiaxun Yang 
Signed-off-by: Huacai Chen 
Signed-off-by: Greg Kroah-Hartman

um: virtio_uml: Fix use-after-free after put_device in probe

2025-09-25T08:58:51+00:00

[ Upstream commit 7ebf70cf181651fe3f2e44e95e7e5073d594c9c0 ]

When register_virtio_device() fails in virtio_uml_probe(),
the code sets vu_dev->registered = 1 even though
the device was not successfully registered.
This can lead to use-after-free or other issues.

Fixes: 04e5b1fb0183 ("um: virtio: Remove device on disconnect")
Signed-off-by: Miaoqian Lin 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

KVM: SVM: Set synthesized TSA CPUID flags

2025-09-19T14:29:56+00:00

Commit f3f9deccfc68a6b7c8c1cc51e902edba23d309d4 in the LTS tree.

VERW_CLEAR is supposed to be set only by the hypervisor to denote TSA
mitigation support to a guest. SQ_NO and L1_NO are both synthesizable,
and are going to be set by hw CPUID on future machines.

So keep the kvm_cpu_cap_init_kvm_defined() invocation *and* set them
when synthesized.

This fix is stable-only.

Co-developed-by: Jinpu Wang 
Signed-off-by: Jinpu Wang 
Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Greg Kroah-Hartman 
Cc:  # 6.1.y
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

KVM: SVM: Return TSA_SQ_NO and TSA_L1_NO bits in __do_cpuid_func()

2025-09-19T14:29:56+00:00

Commit c334ae4a545a ("KVM: SVM: Advertise TSA CPUID bits to guests")
set VERW_CLEAR, TSA_SQ_NO and TSA_L1_NO kvm_caps bits that are
supposed to be provided to guest when it requests CPUID 0x80000021.
However, the latter two (in the %ecx register) are instead returned as
zeroes in __do_cpuid_func().

Return values of TSA_SQ_NO and TSA_L1_NO as set in the kvm_cpu_caps.

This fix is stable-only.

Cc:  # 6.1.y
Fixes: c334ae4a545a ("KVM: SVM: Advertise TSA CPUID bits to guests")
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: Move open-coded CPUID leaf 0x80000021 EAX bit propagation code

2025-09-19T14:29:56+00:00

Commit c35ac8c4bf600ee23bacb20f863aa7830efb23fb upstream

Move code from __do_cpuid_func() to kvm_set_cpu_caps() in preparation for adding
the features in their native leaf.

Also drop the bit description comments as it will be more self-describing once
the individual features are added.

Whilst there, switch to using the more efficient cpu_feature_enabled() instead
of static_cpu_has().

Note, LFENCE_RDTSC and "NULL selector clears base" are currently synthetic,
Linux-defined feature flags as Linux tracking of the features predates AMD's
definition.  Keep the manual propagation of the flags from their synthetic
counterparts until the kernel fully converts to AMD's definition, otherwise KVM
would stop synthesizing the flags as intended.

Signed-off-by: Kim Phillips 
Signed-off-by: Borislav Petkov (AMD) 
Acked-by: Sean Christopherson 
Link: https://lore.kernel.org/r/20230124163319.2277355-3-kim.phillips@amd.com

Move setting of VERW_CLEAR bit to the new
kvm_cpu_cap_mask(CPUID_8000_0021_EAX, ...) site.

Cc:  # 6.1.y
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

x86/vmscape: Add old Intel CPUs to affected list

2025-09-11T15:19:16+00:00

Commit 8a68d64bb10334426834e8c273319601878e961e upstream.

These old CPUs are not tested against VMSCAPE, but are likely vulnerable.

Signed-off-by: Pawan Gupta 
Signed-off-by: Dave Hansen 
Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Greg Kroah-Hartman

x86/vmscape: Warn when STIBP is disabled with SMT

2025-09-11T15:19:16+00:00

Commit b7cc9887231526ca4fa89f3fa4119e47c2dc7b1e upstream.

Cross-thread attacks are generally harder as they require the victim to be
co-located on a core. However, with VMSCAPE the adversary targets belong to
the same guest execution, that are more likely to get co-located. In
particular, a thread that is currently executing userspace hypervisor
(after the IBPB) may still be targeted by a guest execution from a sibling
thread.

Issue a warning about the potential risk, except when:

- SMT is disabled
- STIBP is enabled system-wide
- Intel eIBRS is enabled (which implies STIBP protection)

Signed-off-by: Pawan Gupta 
Signed-off-by: Dave Hansen 
Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Greg Kroah-Hartman

x86/bugs: Move cpu_bugs_smt_update() down

2025-09-11T15:19:15+00:00

Commit 6449f5baf9c78a7a442d64f4a61378a21c5db113 upstream.

cpu_bugs_smt_update() uses global variables from different mitigations. For
SMT updates it can't currently use vmscape_mitigation that is defined after
it.

Since cpu_bugs_smt_update() depends on many other mitigations, move it
after all mitigations are defined. With that, it can use vmscape_mitigation
in a moment.

No functional change.

Signed-off-by: Pawan Gupta 
Signed-off-by: Dave Hansen 
Reviewed-by: Dave Hansen 
Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Greg Kroah-Hartman