CVE-2026-98970

What it actually does

Memory leak in vc4_bo_cache_destroy where the BO cache size list is never freed after purging cached BOs, causing a leak on every driver unbind.

Why it matters to the business

Gradual memory exhaustion on systems repeatedly binding and unbinding the vc4 driver, leading to performance degradation and potential crashes over extended operation; low urgency due to very low EPSS and no known exploitation.

How an attack unfolds

An attacker with local access triggers repeated driver unbind operations through graphics or module load/unload sequences, accumulating leaked memory until the system is destabilized.

How to fix it

Update to a Linux kernel containing the fix that frees the BO cache size list in vc4_bo_cache_destroy; rebuild and deploy the patched kernel across affected systems.

How to confirm the fix worked

Inspect the vc4_bo_cache_destroy function in the kernel source to confirm the size list is explicitly freed; monitor kernel memory usage during bind/unbind cycles to verify no ongoing leaks.

Typical attack path

1. Obtain local access to a system using the vc4 DRM driver
2. Trigger multiple bind/unbind cycles via graphics API calls or module reloads
3. Accumulate unreleased size list allocations over repeated operations
4. Observe system memory pressure and potential denial of service

How to detect it

Review kernel logs and memory statistics for unexpected growth tied to vc4 module activity; examine unbind events in dmesg or system logs for patterns indicating repeated teardown without corresponding frees.

What your security team should do

• Prioritize kernel updates for systems using vc4 graphics within standard patch windows
• Monitor memory utilization trends on affected hardware
• Limit unprivileged access to driver bind/unbind operations where feasible