CVE-2023-52838

What it actually does

The probe routine for the imsttfb framebuffer driver leaks a previously allocated memory mapping when init_imstt() returns an error, because iounmap(par->cmap_regs) is omitted on that path.

Why it matters to the business

Repeated driver load failures on systems using this legacy framebuffer hardware can gradually exhaust kernel virtual address space or pinned memory, leading to degraded stability on long-lived servers or embedded devices; the issue has low external exploitability and no known ransomware usage.

How an attack unfolds

An attacker with the ability to trigger repeated probe attempts (for example by loading and unloading the module or causing hardware initialization to fail) can cause the kernel to leak ioremap mappings, eventually consuming limited kernel resources and producing a localized denial-of-service condition.

How to fix it

Upgrade to a fixed Linux kernel version containing commit 382e1931e0c9cd58a5a8519cdc6cd9dc4d82b485 or later; distribution kernels based on 4.19.299 and corresponding stable branches already contain the correction. Rebuild and reboot with the updated kernel; no configuration changes are required.

How to confirm the fix worked

Confirm the running kernel contains the cited commit or is at least version 4.19.299; inspect the imsttfb probe error path to verify iounmap(par->cmap_regs) is now executed on all failure returns from init_imstt().

Typical attack path

1. Obtain local access or the ability to load kernel modules on the target system
2. Cause the imsttfb driver to be probed while init_imstt() fails
3. Repeat the failure condition to accumulate unmapped regions
4. Trigger memory-pressure or address-space exhaustion that affects other kernel operations

How to detect it

Review kernel logs for repeated imsttfb probe failures; look for patterns of ioremap allocations without matching iounmap calls in memory-pressure or OOM reports. No public exploit artifacts or threat-actor campaigns are associated with this issue.

What your security team should do

• Apply the kernel update during the next planned maintenance window
• Prioritize systems that expose the imsttfb driver or run legacy graphics hardware
• Monitor EPSS and exploit maturity; currently both remain negligible