Linux Kernel EUVD-2026-45713

Exploitation requires the host to be running KVM with AMD SEV or SEV-ES confidential VMs enabled, and the attacker must already control a running SEV/SEV-ES guest that can issue GHCB VMGEXIT Port I/O requests - this is inherently a local, guest-to-host attack (AV:L, S:C), not remote-unauthenticated. The specific trigger is a PIO request with length '0' or repeat count '0' reaching the software scratch-area setup. Limiting factors: hosts without AMD SEV/SEV-ES or without confidential guests are not affected at all; the attacker needs an existing foothold in a guest VM; and the practical impact appears bounded to host-side WARN/OOB conditions rather than demonstrated code execution, so realistic risk is confined to multi-tenant AMD SEV deployments running untrusted guests.

The signals conflict sharply and should be reconciled before prioritization. The CVSS base score is 9.3 with vector AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H - the S:C (scope change) reflects a guest-to-host boundary crossing, which is why an ostensibly local bug scores critical. However, EPSS is only 0.20% (10th percentile), there is no CISA KEV listing (not actively exploited), and no public exploit code was identified, indicating low near-term real-world exploitation pressure. The vendor tag is 'Information Disclosure' and the actual patch is a small hardening change (ignore len==0 PIO), which suggests the practical worst case is bounded - most likely a host-side WARN/DoS or limited OOB read rather than reliable RCE, notwithstanding the C:H/I:H/A:H rating. Note the PR:N in the provided vector is questionable: exploitation requires the attacker to already control a running SEV/SEV-ES guest, which is a privilege boundary; treat 'unauthenticated' with caution. Bottom line: this is a real but low-priority defense-in-depth fix for hosts that actually run AMD SEV confidential VMs, not an urgent internet-facing critical.

An attacker who controls a malicious SEV/SEV-ES guest issues a crafted VMGEXIT PIO request with a repeat count or length of zero, driving the host's GHCB scratch-area setup into a length-underflow condition. On an unpatched host this could trigger a host-side WARN/instability or a limited out-of-bounds access consistent with the 'Information Disclosure' tag. No public proof-of-concept was identified, and reliable exploitation would require deep control of the guest-host GHCB interaction.