CVE-2025-38612

What it actually does

The vulnerability is a memory leak of pagerefs allocated inside fb_deferred_io_init() when error paths are taken after fb_info has already been successfully allocated inside fbtft_framebuffer_alloc().

Why it matters to the business

Systems relying on the fbtft staging driver may experience gradual kernel memory exhaustion under repeated error conditions, increasing operational risk on embedded or display-equipped Linux deployments; downstream package prevalence is limited.

How an attack unfolds

An attacker with local access triggers framebuffer allocation paths that succeed at the fb_info stage but later fail, bypassing the missing cleanup of info->pagerefs; repeated triggering slowly depletes memory without any external network activity.

How to fix it

Apply the upstream fix (commit 83ea0c7b8d12c67f6c4703d6c458627a7fc45fc0) or later; upgrade affected Chainguard packages (openjdk-21-openj9 and variants) to version 0.53.0-r0.

How to confirm the fix worked

Confirm the error-path cleanup call is present in fbtft_framebuffer_alloc(); verify running kernel or package versions match the listed fixed revisions.

Typical attack path

1. Obtain local execution context on a system using the fbtft driver
2. Force error conditions during fbtft_framebuffer_alloc() after fb_info allocation
3. Repeat allocation attempts to accumulate unfreed pagerefs memory
4. Observe progressive kernel memory pressure or OOM events

How to detect it

Look for unexplained kernel memory growth correlated with fbtft framebuffer operations; examine dmesg or slabinfo for increasing pagerefs allocations without corresponding frees.

What your security team should do

• Prioritize kernel and package updates on any systems exposing the fbtft driver
• Remove or disable staging fbtft usage where feasible
• Add memory-usage monitoring for kernel framebuffer allocations
• Review container or embedded images for outdated fbtft builds