CVE-2021-47144

What it actually does

Refcount leak on AMD GPU framebuffer gem objects: rfb->base.obj[0] is acquired per num_planes in amdgpufb_create but never released per num_planes in amdgpu_fbdev_destroy, allowing reference counts to remain elevated and preventing object release.

Why it matters to the business

On systems with AMD GPUs, repeated framebuffer operations can exhaust memory or graphics resources, leading to application crashes, display instability, or eventual kernel memory pressure that disrupts workloads.

How an attack unfolds

An attacker with local access triggers repeated creation and destruction of AMD GPU framebuffers (for example via graphics applications or display reconfiguration) to accumulate unreleased gem object references; over time this produces resource exhaustion or creates conditions for later use-after-free exploitation once the leaked objects are eventually freed.

How to fix it

Update to fixed kernel versions: linux 5.10.46-1 (Debian 11), 5.14.6-1 (Debian 12/13); for AlmaLinux 8 update gcc-toolset-11-binutils and gcc-toolset-11-binutils-devel to 2.36.1-1.el8_5.1. Reboot into the patched kernel after installation.

How to confirm the fix worked

Verify running kernel version matches or exceeds the listed fixed releases for each distribution; inspect dmesg or kernel logs for absence of prior refcount warnings related to amdgpu_fbdev_destroy; confirm with package manager that the updated linux-image or binutils packages are installed.

Typical attack path

1. Obtain local user access on an affected Linux system with AMD GPU
2. Execute or induce graphics workloads that call amdgpufb_create
3. Trigger corresponding destruction paths that omit the matching put operations
4. Repeat to accumulate leaked references until memory or GPU resource limits are reached

How to detect it

Review kernel logs for repeated amdgpu framebuffer allocation patterns without matching deallocation; correlate with process activity that performs frequent display or graphics initialization; examine memory usage trends on AMD GPU systems for unexplained growth after graphics operations.

What your security team should do

• Prioritize kernel upgrades on all AMD GPU hosts within the next maintenance window
• Restrict unprivileged local graphics access where feasible until patches are applied
• Monitor for memory or GPU resource exhaustion indicators on affected systems
• Include the fixed package versions in automated patch compliance reporting