CVE-2025-68230

What it actually does

Incorrect restoration of partition mode registers after Mode1 reset on hibernation resume in PF passthrough leads to wrong stride size when CP accesses the MQD BO, resulting in out-of-bounds access and GPU page fault on AMD GPUs.

Why it matters to the business

Systems using affected AMD GPUs in virtualization passthrough setups risk crashes or instability after sleep/wake cycles, with limited ecosystem prevalence and no ransomware usage or CISA deadlines increasing urgency.

How an attack unfolds

In a PF passthrough environment, an attacker triggers hibernation followed by resume, then invokes a compute workload such as coralgemm to hit the un-restored partition state and induce the page fault.

How to fix it

Apply kernel updates containing commit a45d6359eefb41e08d374a3260b10bff5626823b or equivalent that calls gfx_v9_4_3_switch_compute_partition() on resume from hibernation; kubernetes-dashboard-api packages require version 1.10.2-r2 or later.

How to confirm the fix worked

Confirm the fix by verifying the presence of the partition switch call in the resume path and testing hibernation/resume cycles with passthrough workloads on affected AMD hardware.

Typical attack path

1. Place the system into hibernation
2. Resume from hibernation without full partition mode restoration
3. Execute a targeted compute workload that accesses the MQD BO

How to detect it

Review kernel logs for GPU page fault messages referencing mmCP_HYP_XCP_CTL or mmCP_PSP_XCP_CTL after hibernation events on AMD hardware.

What your security team should do

• Prioritize kernel upgrades on systems with AMD GPUs used in passthrough
• Test hibernation/resume behavior after patching
• Monitor for page fault reports in dmesg on unpatched hosts