CVE-2021-47431

What it actually does

Unmatched gart_enable/gart_disable calls in the amdgpu driver under SR-IOV cause a persistent pin_count leak on gart.bo, leaving reference counts elevated after driver unload.

Why it matters to the business

Systems using AMD GPUs with SR-IOV virtualization may experience gradual memory exhaustion and reduced stability after repeated driver load/unload cycles, increasing operational overhead for maintenance and potential downtime.

How an attack unfolds

An attacker with local access or the ability to trigger driver reloads in an SR-IOV environment repeatedly unloads and reloads the amdgpu driver, accumulating the pin_count leak until system memory pressure leads to denial of service or forces a reboot.

How to fix it

Update to a Linux kernel containing the fix for the mismatched gart calls in gmc_v9_0 and gmc_v10_0 SR-IOV paths; rebuild and deploy the corrected amdgpu module.

How to confirm the fix worked

Confirm the presence of matching gart_enable/gart_disable calls in gmc_v{9,10}_0_gart paths after kernel update; monitor pin_count stability across driver unload/load in SR-IOV configurations.

Typical attack path

1. Obtain local access or control over a VM using SR-IOV GPU passthrough
2. Trigger repeated amdgpu driver unload/load sequences
3. Accumulate leaked pin_count references across cycles
4. Induce memory pressure or driver instability on host

How to detect it

Review kernel logs for repeated amdgpu gart enable/disable mismatches during module unload; inspect memory accounting counters for gart.bo objects after driver reload cycles.

What your security team should do

• Prioritize kernel updates on hosts using AMD SR-IOV GPU configurations
• Audit virtualization setups for repeated driver reload patterns
• Monitor memory usage trends on affected systems until patched