CVE-2021-47421

What it actually does

Unconditional release of a write lock in amdgpu_pci_resume without prior acquisition when PCI channel state is normal instead of frozen, allowing subsequent read lock attempts by other threads to deadlock.

Why it matters to the business

AMD GPU systems may hang or become unresponsive during PCI error recovery, disrupting graphics workloads and requiring reboots.

How an attack unfolds

An error condition or attacker-induced PCI fault transitions the channel state to normal; the PCI core then calls the resume path which releases an unheld lock, after which any concurrent reader blocks indefinitely.

How to fix it

Apply a Linux kernel update that adds pci_channel_state caching to amdgpu_device and gates execution of amdgpu_pci_resume on pci_channel_io_frozen only.

How to confirm the fix worked

Inspect the amdgpu_device structure for the added state member and confirm the conditional guard exists before any lock release inside amdgpu_pci_resume.

Typical attack path

1. Induce or wait for a PCI channel error state transition to normal
2. PCI driver walks the bridge and invokes amdgpu_pci_resume
3. Function releases write lock without having acquired it
4. Other kernel threads attempting read lock on the same structure deadlock

How to detect it

Search kernel logs for amdgpu PCI resume entries, lockdep warnings, or hung task reports involving the DRM subsystem around the time of PCI AER events.

What your security team should do

• Prioritize kernel package updates on all AMD GPU hosts
• Enable PCI AER logging to detect error state transitions
• Test resume behavior under injected PCI faults after patching