CVE-2021-47530

What it actually does

Reference count leak on submitqueue object in the MSM DRM driver when wait_fence is called on an already-signaled fence, preventing proper cleanup across multiple return paths and causing a resource leak.

Why it matters to the business

Linux systems using Qualcomm graphics hardware may experience gradual memory exhaustion or instability during graphics operations, potentially requiring reboots and affecting device uptime in servers, desktops, or embedded devices.

How an attack unfolds

An attacker with local code execution on an affected Linux kernel triggers the wait_fence path on a pre-signaled fence, exploiting incomplete reference handling to leak submitqueue objects without triggering the fix helper.

How to fix it

Update to a Linux kernel version containing the referenced fix for drm/msm wait_fence submitqueue handling; apply the patch that introduces the helper to ensure reference drops on all paths.

How to confirm the fix worked

Confirm the kernel source includes the helper function for fence signaling paths and that reference counts are decremented before all returns in wait_fence; test by exercising signaled fence scenarios and monitoring for leaks via kmemleak or similar tools.

Typical attack path

1. Obtain local execution context on a Linux system with MSM DRM enabled
2. Allocate and signal a fence object via graphics APIs
3. Invoke wait_fence on the already-signaled fence to hit the leaky return path
4. Repeat to accumulate unreleased submitqueue references

How to detect it

Review kernel logs for repeated MSM DRM fence and submitqueue operations; inspect for anomalous reference counts or memory growth patterns tied to graphics workloads using tools like kmemleak after triggering fence wait paths.

What your security team should do

• Prioritize kernel updates on systems with Qualcomm Adreno graphics
• Monitor for upstream stable kernel releases post-2024-05-24 containing this fix
• Restrict unprivileged local access where possible until patched