On Fri, Sep 19, 2025 at 10:42:33PM +0530, Harshit Mogalapalli wrote:

Hi stable maintainers,

While skimming over stable backports for VMSCAPE commits, I found something unusual.

This is regarding the 6.12.y commit: 7c62c442b6eb ("x86/vmscape: Enumerate VMSCAPE bug")

commit 7c62c442b6eb95d21bc4c5afc12fee721646ebe2 Author: Pawan Gupta pawan.kumar.gupta@linux.intel.com Date: Thu Aug 14 10:20:42 2025 -0700

x86/vmscape: Enumerate VMSCAPE bug

Commit a508cec6e5215a3fbc7e73ae86a5c5602187934d upstream.

The VMSCAPE vulnerability may allow a guest to cause Branch Target
Injection (BTI) in userspace hypervisors.

Kernels (both host and guest) have existing defenses against direct BTI
attacks from guests. There are also inter-process BTI mitigations which
prevent processes from attacking each other. However, the threat in this
case is to a userspace hypervisor within the same process as the

attacker.

Userspace hypervisors have access to their own sensitive data like disk
encryption keys and also typically have access to all guest data. This
means guest userspace may use the hypervisor as a confused deputy to

attack sensitive guest kernel data. There are no existing mitigations for these attacks.

Introduce X86_BUG_VMSCAPE for this vulnerability and set it on affected
Intel and AMD CPUs.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

So the problem in this commit is this part of the backport:

in file: arch/x86/kernel/cpu/common.c

    VULNBL_AMD(0x15, RETBLEED),
    VULNBL_AMD(0x16, RETBLEED),

•   VULNBL_AMD(0x17, RETBLEED | SMT_RSB | SRSO),
  

•   VULNBL_HYGON(0x18, RETBLEED | SMT_RSB | SRSO),
  

•   VULNBL_AMD(0x19, SRSO | TSA),
  

•   VULNBL_AMD(0x17, RETBLEED | SMT_RSB | SRSO | VMSCAPE),
  

•   VULNBL_HYGON(0x18, RETBLEED | SMT_RSB | SRSO | VMSCAPE),
  

•   VULNBL_AMD(0x19, SRSO | TSA | VMSCAPE),
  

•   VULNBL_AMD(0x1a, SRSO | VMSCAPE),
  

•   {}
  
  

Notice the part where VULNBL_AMD(0x1a, SRSO | VMSCAPE) is added, 6.12.y doesn't have commit: 877818802c3e ("x86/bugs: Add SRSO_USER_KERNEL_NO support") so I think we shouldn't be adding VULNBL_AMD(0x1a, SRSO | VMSCAPE) directly.

Boris Ostrovsky suggested me to verify this on a Turin machine as this could cause a very big performance regression : and stated if SRSO mitigation status is Safe RET we are likely in a problem, and we are in that situation.

# lscpu | grep -E "CPU family" CPU family: 26

Notes: CPU ID 26 -> 0x1a

And Turin machine reports the SRSO mitigation status as "Safe RET"

# uname -r 6.12.48-master.20250917.el8.rc1.x86_64

# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow Mitigation: Safe RET

Boris Ostrovsky suggested backporting three commits to 6.12.y:

1. commit: 877818802c3e ("x86/bugs: Add SRSO_USER_KERNEL_NO support")
2. commit: 8442df2b49ed ("x86/bugs: KVM: Add support for SRSO_MSR_FIX") and

its fix 3. commit: e3417ab75ab2 ("KVM: SVM: Set/clear SRSO's BP_SPEC_REDUCE on 0 <=> 1 VM count transitions") -- Maybe optional

After backporting these three:

# uname -r 6.12.48-master.20250919.el8.dev.x86_64 // Note this this is kernel with patches above three applied.

# dmesg | grep -C 2 Reduce [ 3.186135] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl [ 3.187135] Speculative Return Stack Overflow: Reducing speculation to address VM/HV SRSO attack vector. [ 3.188134] Speculative Return Stack Overflow: Mitigation: Reduced Speculation [ 3.189135] VMSCAPE: Mitigation: IBPB before exit to userspace [ 3.191139] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'

# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow Mitigation: Reduced Speculation

I can send my backports to stable if this looks good. Thoughts ?

Please submit them if they solve this issue, thank you!