CVE-2021-47534

What it actually does

Missing drm_crtc_commit_put call in vc4 KMS commit handling causes drm_crtc_commit structures to be leaked on every CRTC commit due to incorrect refcounting after introduction of global HVS FIFO state.

Why it matters to the business

Prolonged operation on systems using the vc4 driver leads to gradual kernel memory exhaustion, increasing risk of out-of-memory kills, degraded graphics performance, and eventual system instability or crashes.

How an attack unfolds

An attacker with the ability to trigger repeated display commits (via local graphics APIs or malicious applications) accelerates the accumulation of unreleased drm_crtc_commit objects, culminating in memory pressure and denial of service; listed threat actors involved in Linux kernel exploitation campaigns could leverage similar resource-handling flaws.

How to fix it

Apply the upstream fix that adds the missing drm_crtc_commit_put call; update to a Linux kernel version released after the patch commit 9ec03d7f1ed3 resolution.

How to confirm the fix worked

Review kernel commit history for the drm_crtc_commit_put addition in vc4 kms code; use memory leak detection tools such as kmemleak or slabinfo to confirm no further drm_crtc_commit growth after repeated commits.

Typical attack path

1. Obtain local execution or application control on vc4-based system
2. Trigger multiple KMS CRTC commits through graphics or display operations
3. Monitor kernel memory consumption to confirm leak progression
4. Continue commit activity until memory pressure causes OOM or instability

How to detect it

Correlate increasing kernel memory usage with display commit activity in dmesg or perf logs; inspect for repeated drm_crtc_commit allocations without corresponding releases in memory profiling tools.

What your security team should do

• Prioritize kernel updates on all vc4-affected devices despite low EPSS and non-KEV status
• Implement memory usage monitoring correlated with display activity
• Restrict untrusted local applications from performing frequent display commits where feasible