In the Linux kernel

CVE-2026-53360 is a guest-triggered heap out-of-bounds read/write in the Linux kernel's KVM SEV-SNP Page State Change (PSC) handler (arch/x86/kvm/svm/sev.c). When a GHCB v2+ guest points its scratch area outside the GHCB, setup_vmgexit_scratch() allocates a host-side buffer sized by guest-controlled exit_info_2. The entry-count validation then checks against the protocol constant 253 (VMGEXIT_PSC_MAX_COUNT) instead of the actual buffer capacity. A guest requesting a 24-byte allocation gets a kmalloc-cg-32 slab but can walk up to index 252, reading and writing adjacent slab objects on the host heap. Introduced in commit 9b54e248d264 (~v6.10, May 2024). Fixed in commit db3f219 (May 2026), backported to 6.1.177, 6.6.144, 6.12.95, 6.18.38, 7.0.14, and 7.1.3. Only the SEV-SNP host path is affected; plain SEV or SEV-ES guests cannot trigger it.

The vendor score of 8.8 HIGH with Scope:Changed (AV:L/AC:L/PR:L/UI:N/S:C) is directionally correct — this is a genuine VM escape primitive. The S:C flag properly reflects guest-to-host boundary crossing, and AC:L is fair because the public PoC is straightforward (73 KASAN violations on a single run against an AMD EPYC 7443P). However, the 8.8 slightly overstates the real-world blast radius because the vulnerable code path is only exercised on hosts actively running SEV-SNP guests, which is a minority of KVM deployments — primarily cloud confidential-computing tiers and regulated on-prem enclaves. noisgate downgrades to 8.0 but floors at HIGH because KVM is a hypervisor component and the chain ends in host compromise.

Why this verdict

• Hypervisor escape primitive: The OOB read/write crosses the guest-host boundary, giving the attacker influence over host kernel memory from inside a VM. Scope:Changed is correctly applied.
• Public PoC with strong primitives: 0xCyberstan's PoC demonstrates read oracle, constrained write, and failure oracle — three building blocks for a full chain. 73 KASAN violations on a single run confirms reliability.
• Role multiplier: KVM is a hypervisor. On confidential-computing hosts (Azure CVM, GCP Confidential VMs, on-prem EPYC enclaves), the blast radius of host compromise is all co-resident VMs plus management plane — fleet-scale impact. This floors the verdict at HIGH.
• Narrow reachable population: Only KVM hosts with CONFIG_KVM_AMD_SEV compiled in AND actively running SEV-SNP guests are vulnerable. This is a single-digit percentage of all Linux KVM deployments, primarily concentrated in cloud CVM tiers and regulated on-prem confidential-computing enclaves. This provides the 0.8-point downward adjustment from 8.8.
• No weaponized exploit chain yet: The PoC demonstrates primitives but not end-to-end code execution. Heap grooming + KASLR bypass are required for full weaponization, adding meaningful attacker effort.

Why not higher?

Upgrading to CRITICAL would require either active in-the-wild exploitation or a broader reachable population. The vulnerable code path is gated behind SEV-SNP guest execution, which is a minority of KVM deployments — most KVM hosts never launch an SNP guest and are entirely unreachable. The PoC demonstrates primitives, not a turnkey exploit, and KASLR adds a second barrier.

Why not lower?

Downgrading below HIGH would violate the hypervisor-role floor. This is a VM escape bug in KVM — the chain demonstrably ends in host kernel memory corruption from an unprivileged guest position. A public PoC with reliable primitives exists. For any organization running SEV-SNP workloads, the blast radius is fleet-scale. The low EPSS reflects attack-surface narrowness, not low impact.

1. Disable SEV-SNP on non-essential hosts — If SEV-SNP is enabled by default but not required for your workloads, disable it via mem_encrypt=off kernel parameter or by not loading the ccp module. This eliminates the vulnerable code path entirely. Deploy within 30 days per noisgate mitigation SLA for HIGH.
2. Pin guest GHCB version to v1 where possible — If your guest images can be controlled, pin GHCB protocol version to v1, which uses a different scratch-area code path. This is a temporary workaround — not all guests support v1 fallback. Deploy within 30 days.
3. Enable KASAN on confidential-compute hosts — Compile with CONFIG_KASAN=y on SEV-SNP hosts to get immediate detection of OOB access in snp_begin_psc. This is a detection control, not prevention, but gives you visibility if exploitation is attempted. Performance overhead of ~2-3x makes this viable only on non-production or canary hosts.
4. Restrict guest kernel module loading — Limit the attacker's ability to load custom kernel modules inside SEV-SNP guests via modules_disabled=1 or signed-module enforcement. This raises the bar from 'unprivileged guest code' to 'guest kernel exploit + module bypass'. Deploy within 30 days.

Run this script on each candidate KVM host (not inside the guest). Requires root to read kernel config. Invoke as: sudo bash check_cve_2026_53360.sh. No arguments needed.

#!/usr/bin/env bash
# CVE-2026-53360 checker — KVM SEV-SNP PSC heap OOB
# Run on KVM HOST as root. Outputs VULNERABLE / PATCHED / UNKNOWN.
set -euo pipefail

RED='\033[0;31m'; GREEN='\033[0;32m'; YELLOW='\033[1;33m'; NC='\033[0m'

# 1. Check if SEV-SNP is even compiled / enabled
SEV_ENABLED=0
if [ -f /sys/module/kvm_amd/parameters/sev_snp ]; then
  SNP_PARAM=$(cat /sys/module/kvm_amd/parameters/sev_snp 2>/dev/null || echo 'N')
  if [ "$SNP_PARAM" = "Y" ] || [ "$SNP_PARAM" = "1" ]; then
    SEV_ENABLED=1
  fi
fi

if [ "$SEV_ENABLED" -eq 0 ]; then
  echo -e "${GREEN}NOT AFFECTED${NC} — SEV-SNP is not enabled on this host."
  echo "PATCHED"
  exit 0
fi

# 2. Get running kernel version
KVER=$(uname -r)
echo "Kernel: $KVER"
echo "SEV-SNP: enabled"

# 3. Check against known-fixed versions
# Fixed in: 6.1.177, 6.6.144, 6.12.95, 6.18.38, 7.0.14, 7.1.3
version_gte() {
  printf '%s\n%s' "$2" "$1" | sort -V -C
}

# Extract base version (strip distro suffixes for comparison)
BASE_VER=$(echo "$KVER" | grep -oP '^[0-9]+\.[0-9]+\.[0-9]+')
MAJOR_MINOR=$(echo "$BASE_VER" | grep -oP '^[0-9]+\.[0-9]+')

case "$MAJOR_MINOR" in
  6.1)  FIX="6.1.177" ;;
  6.6)  FIX="6.6.144" ;;
  6.12) FIX="6.12.95" ;;
  6.18) FIX="6.18.38" ;;
  7.0)  FIX="7.0.14" ;;
  7.1)  FIX="7.1.3" ;;
  7.2|7.3|7.4|7.5|8.*) FIX="0.0.0" ;;  # post-fix mainline
  *)    echo -e "${YELLOW}UNKNOWN${NC} — kernel $KVER not in checked branches."
        echo "UNKNOWN"
        exit 2 ;;
esac

if [ "$FIX" = "0.0.0" ] || version_gte "$BASE_VER" "$FIX"; then
  echo -e "${GREEN}PATCHED${NC} — $KVER >= $FIX"
  echo "PATCHED"
  exit 0
else
  echo -e "${RED}VULNERABLE${NC} — $KVER < $FIX (fixed in $FIX)"
  echo "VULNERABLE"
  exit 1
fi

Sources

1. 0xCyberstan PoC — CVE-2026-53360
2. TechVeda — Linux Kernel CVEs to Patch (27 Jun – 4 Jul 2026)
3. LWN — Seven stable kernels for Saturday
4. TechVeda — Linux Kernel CVEs (18–25 Jul 2026)
5. CISA Known Exploited Vulnerabilities Catalog
6. LKML — KVM SEV scratch area patch context
7. Red Hat Security Advisory RHSA-2026:34911