Ubuntu’s USN‑7860‑5 patches VMSCAPE (CVE‑2025‑40300) in HWE kernels: DFIR response notes

Canonical published USN-7860-5 on November 10, 2025 for Ubuntu 24.04 LTS HWE (6.14) to mitigate VMSCAPE (CVE-2025-40300), a Spectre-class issue where insufficient branch-predictor isolation lets a guest VM influence host userspace execution and leak data from processes like QEMU. The notice requires updating to 6.14.0-35 and rebooting; it also flags an ABI bump that will rebuild third-party kernel modules. (ubuntu.com)

Intrusion Flow

• Guest training: A malicious guest poisons branch-predictor state (vBTI) while executing under KVM. On VMEXIT, host userspace (e.g., QEMU) runs with the tainted predictor, enabling Spectre-BTI-style mis-speculation and data disclosure via a cache side channel. (intel.com)
• Target surface: The attack impacts userspace hypervisors; existing kernel/KVM Spectre defenses are not sufficient because the userspace VMM can run immediately after VMEXIT without a context switch. (ubuntu.com)
• Practicality: Researchers report end-to-end exfiltration from a host userspace hypervisor, with measured leak rates on modern CPUs in public write-ups. (linuxjournal.com)
• Affected CPUs: Kernel documentation lists Intel Skylake (parts without eIBRS), Cascade Lake (ITS guest/host separation), and Alder Lake and newer (BHI), plus AMD Zen families 0x17/0x19/0x1a and Hygon 0x18. Some BHI-affected Intel parts using BHB clearing (e.g., Icelake) are not vulnerable. (docs.kernel.org)
• Kernel mitigation model: Linux adds conditional branch-predictor flushing around VMEXIT-IBPB before returning to userspace-and offers a more aggressive IBPB-on-every-VMEXIT mode; vendors note existing BTI/BHI guidance applies. (docs.kernel.org)

Key Artifacts to Pull

When you’re triaging Ubuntu virtualization hosts, collect:

• Mitigation state: /sys/devices/system/cpu/vulnerabilities/vmscape and related vulnerability files for your case notes. Expect values like Not affected, Vulnerable, Mitigation: IBPB before exit to userspace, or Mitigation: IBPB on VMEXIT. (docs.kernel.org)
• Kernel version and boot parameters:
  • uname -r to confirm 6.14.0-35 or newer on 24.04 HWE. (ubuntu.com)
  • cat /proc/cmdline to record any vmscape= setting (e.g., ibpb, off, force). (docs.kernel.org)
• Package provenance on Ubuntu 24.04 HWE:
  • apt-cache policy linux-image-generic-hwe-24.04 linux-image-6.14.0-35-generic to confirm the USN-listed versions (6.14.0-35.35~24.04.1) and metapackages. (ubuntu.com)
• Module rebuild evidence after ABI bump:
  • dkms status and dmesg excerpts to show out-of-tree drivers were rebuilt. The USN explicitly calls out an ABI change requiring third-party module recompiles. (ubuntu.com)
• Hypervisor stack context:
  • qemu-system-x86_64 --version, libvirt logs, and KVM exit telemetry for timeline/context. Use perf/trace tooling (examples below) to capture VMEXIT patterns during the incident window. (linux-kvm.org)

Example collection snippet:

# Mitigation status and kernel facts
cat /sys/devices/system/cpu/vulnerabilities/vmscape
uname -r
cat /proc/cmdline | sed 's/ \+/\n/g' | grep -i vmscape

# Ubuntu packages (24.04 HWE example)
apt-cache policy linux-image-6.14.0-35-generic linux-image-generic-hwe-24.04

# DKMS/module rebuilds after ABI bump
sudo dkms status | sed 's/,/\n/g'
dmesg -T | egrep -i 'vmscape|IBPB|branch|specu|module|dkms'

# KVM exit telemetry (context only; not an exploit detector)
sudo perf stat -e 'kvm:*' -a sleep 60
sudo kvmexit 10   # from bpfcc-tools if installed

Detection Notes

• There is no reliable host log that proves a VMSCAPE data leak; treat this as a hardening and exposure-reduction issue rather than an IOC hunt. Verify the mitigation state via the VMSCAPE sysfs entry and kernel parameters. (docs.kernel.org)
• For situational awareness, you can watch KVM exit behavior during suspicious guest activity. Use perf tracepoints (kvm:kvm_exit, kvm:kvm_entry) or bpfcc’s kvmexit to profile exit reasons and volume; this is supporting context only and not a definitive indicator of exploitation. (linux-kvm.org)
• If Simultaneous Multi-Threading (SMT) is enabled on affected hosts, ensure STIBP protection is active; kernel docs state STIBP (or eIBRS) is required for complete protection in SMT environments. (docs.kernel.org)

Response Guidance

• Patch window and reboot: Apply USN-7860-5 on Ubuntu 24.04 LTS HWE and reboot to activate mitigations; plan for a kernel ABI change that triggers third-party module rebuilds. Version targets in Canonical’s notice include linux-image 6.14.0-35.35~24.04.1. (ubuntu.com)
• Validate mitigations:
  • After reboot, confirm /sys/devices/system/cpu/vulnerabilities/vmscape shows a mitigation, not Vulnerable. (docs.kernel.org)
  • If your threat model includes untrusted guests and you cannot upgrade hardware immediately, consider enforcing the conservative vmscape=ibpb mode; document the performance trade-off as part of the change request. (docs.kernel.org)
• Secret rotation (risk-based): VMScape demonstrations and reporting indicate host userspace secrets (including encryption keys) can be recovered; review and rotate sensitive material present in the host VMM context (e.g., per-host admin keys, libvirt/QEMU process-accessible encryption keys, service tokens). (linuxjournal.com)
• CPU fleet review: Map affected CPU families in your estate (Intel Skylake/Cascade Lake/modern BHI-affected parts; AMD Zen families) and prioritize scheduling on those hosts that run untrusted or multi-tenant guests. (docs.kernel.org)
• Performance considerations: Expect some overhead from IBPB flushing on frequent VMEXIT/host-userspace transitions; capture baseline perf counters before and after enabling stricter modes, then adjust host consolidation accordingly. Vendor and kernel guidance ties the mitigation to IBPB on returns to userspace or VMEXIT. (docs.kernel.org)

Takeaways

• Patch and reboot Ubuntu 24.04 HWE hosts to USN-7860-5 (6.14.0-35) now, and verify /sys/.../vmscape shows a mitigation. (ubuntu.com)
• Where SMT is enabled, ensure STIBP/eIBRS protections are in place. (docs.kernel.org)
• Treat potential exposure as a secret-management problem: rotate high-value host userspace secrets that VMMs handle. (linuxjournal.com)
• Use perf/KVM tracing to understand VMEXIT patterns during investigations, but don’t rely on them as exploitation indicators. (linux-kvm.org)