CVE-2026-43202

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel framebuffer driver for vt8500lcdfb. During an error path, memory allocated with dma_alloc_coherent() for the framebuffer screen buffer is not released with dma_free_coherent(). Repeatedly triggering the affected initialization/error path can leak coherent DMA memory, eventually exhausting available kernel/DMA memory and degrading or preventing normal system operation. The CVSS vector indicates local access is required, low attack complexity, low privileges, no user interaction, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can cause affected Linux systems using the vulnerable framebuffer driver to become unstable, degraded, or unavailable. The practical risk is highest for embedded, appliance, industrial, kiosk, or legacy ARM-based systems that include or load the vt8500lcdfb driver. There is currently no known public exploitation, no CISA KEV listing, no ransomware association, and EPSS is very low and flat, so broad internet-scale exploitation is unlikely; however, organizations with exposed local shell access, multi-user systems, or embedded fleets should still remediate to prevent avoidable outages.

How an attack unfolds

An attacker must already have local, low-privileged access to an affected Linux system. The attacker identifies that the vulnerable vt8500lcdfb framebuffer driver is present and can be exercised. They then repeatedly trigger the driver initialization or failure path that allocates coherent DMA memory but exits without freeing it. Each failed attempt consumes kernel DMA-capable memory. Over time, this memory leak can exhaust relevant memory pools, causing driver failures, broader kernel memory pressure, degraded services, hangs, or a system crash/reboot. Because the bug does not provide memory disclosure or overwrite primitives, it is best understood as an availability attack rather than a path to code execution or privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for vt8500lcdfb ensuring fbi->fb.screen_buffer allocated by dma_alloc_coherent() is released with dma_free_coherent() on the error path. No exact fixed package versions were provided, so use vendor kernel advisories for the affected distribution, appliance, or embedded platform and apply the latest stable/security kernel update. Where immediate patching is not possible, mitigate by disabling or blacklisting the vt8500lcdfb driver if it is not required, removing framebuffer support from custom kernels where feasible, restricting local shell access, and limiting the ability of untrusted users to load/unload kernel modules or interact with framebuffer devices.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or build includes the vendor fix for this issue. For source-based or embedded kernels, review the vt8500lcdfb error path and confirm every successful dma_alloc_coherent() allocation for fbi->fb.screen_buffer is paired with dma_free_coherent() on all failure paths. Check whether the driver is present or loaded using commands such as lsmod, modinfo vt8500lcdfb, grep of /proc/modules, or inspection of the kernel configuration for VT8500 framebuffer support. Validate that patched systems remain stable when framebuffer initialization failure paths are exercised in a test environment and that DMA/kernel memory usage does not grow unbounded across repeated failures.

Typical attack path

1. Obtain local access to an affected Linux system with low privileges.
2. Confirm the running kernel includes the vulnerable vt8500lcdfb framebuffer driver or that the module is available.
3. Trigger the relevant framebuffer driver probe/initialization path in a way that reaches the error condition after dma_alloc_coherent() succeeds.
4. Repeat the trigger to leak coherent DMA memory each time the error path is reached.
5. Continue until DMA/kernel memory pressure causes driver failure, system instability, service disruption, or a crash.

How to detect it

To determine whether this was already exploited, focus on local activity and kernel stability evidence rather than network indicators. Review kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and persistent crash logs for repeated vt8500lcdfb or framebuffer initialization failures, DMA allocation messages, out-of-memory conditions, kernel warnings, watchdog resets, or unexpected reboots. Correlate these events with local login records, sudo history, shell history where available, module load/unload activity, and access to framebuffer devices. Look for repeated attempts to load, bind, unbind, or initialize the vt8500lcdfb driver shortly before memory exhaustion or system instability. There are no known public exploit-specific artifacts or threat actor tradecraft for this vulnerability, so detection should rely on behavioral patterns around repeated driver error-path triggering and resource exhaustion.

• vt8500lcdfb
• dma_alloc_coherent
• dma_free_coherent
• framebuffer
• fbdev
• /dev/fb0
• /proc/modules
• /sys/bus/platform/drivers/vt8500lcdfb
• Out of memory
• oom-killer
• Kernel panic
• watchdog: watchdog0: watchdog did not stop
• module vt8500lcdfb

What your security team should do

• Prioritize identification of systems that run Linux kernels with vt8500lcdfb support, especially embedded, appliance, kiosk, industrial, or legacy ARM devices.
• Apply vendor kernel updates that include the fix; for custom kernels, backport the upstream dma_free_coherent() cleanup patch.
• If the driver is not required, disable or blacklist vt8500lcdfb to remove the vulnerable code path.
• Restrict local access to trusted users only and review whether untrusted users can interact with framebuffer devices or influence module loading.
• Monitor affected systems for unexplained kernel memory pressure, repeated framebuffer driver failures, hangs, watchdog resets, or crashes.
• Treat this as lower urgency than remotely exploitable KEV/ransomware vulnerabilities, but include it in normal kernel maintenance because the availability impact can be high on affected devices.