CVE-2026-43269

What it actually does

This vulnerability is a memory leak in the Linux kernel Direct Rendering Manager driver for Atmel HLCDC graphics hardware. When atomic plane state is destroyed, the affected code releases the framebuffer reference but fails to release all objects associated with the DRM atomic state, including commit-related allocations. A local user able to exercise the DRM/KMS interface can repeatedly trigger display configuration operations, causing kernel slab memory to grow over time. The primary impact is availability degradation or denial of service due to memory exhaustion; there is no indication of direct confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels with Atmel HLCDC graphics support may become unstable or unavailable after prolonged graphics activity or repeated display configuration changes. This is most relevant for embedded Linux devices, kiosks, industrial control panels, HMI systems, appliances, and other devices that rely on this display controller. Because exploitation requires local access or a local process capable of issuing DRM ioctls, the risk is lower than a remote flaw, but affected devices may still experience crashes, service interruption, watchdog resets, or degraded reliability if an untrusted local workload or compromised application can trigger the leak repeatedly.

How an attack unfolds

An attacker first obtains the ability to run code locally on an affected Linux system or compromises an application with access to the DRM device node. The attacker then repeatedly performs display mode-setting or atomic commit operations through DRM/KMS interfaces, such as invoking ioctls that reach drm_mode_setcrtc, drm_atomic_commit, and drm_atomic_helper_commit. On vulnerable kernels using the Atmel HLCDC DRM driver, each cycle can leave some DRM commit-related memory unreleased because the destroy-state callback does not fully clean up associated atomic state objects. Over time, repeated triggering increases slab memory consumption until the system experiences memory pressure, performance degradation, application failures, kernel warnings, out-of-memory conditions, or a reboot/hang. No public exploit maturity is indicated, the EPSS score is very low, and the issue is not listed in the CISA KEV catalog, so broad active exploitation is not currently suggested by the supplied data.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the upstream fix for the Atmel HLCDC DRM driver atomic_destroy_state memory leak. The fix changes the cleanup path to use the DRM atomic helper state-destruction routine so that all no-longer-needed objects are released, not only the framebuffer reference. Because no exact fixed package versions were provided, use the affected distribution, device vendor, or kernel maintainer advisory to identify the corrected build for each supported platform. If immediate patching is not possible, reduce exposure by limiting local user access, restricting access to DRM device nodes such as /dev/dri/* to trusted users and processes only, disabling unused graphics stacks where operationally feasible, removing or disabling the atmel-hlcdc driver on systems that do not require it, and monitoring memory growth on affected devices. Kernel-level memory leaks generally cannot be fully mitigated without applying the code fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or custom kernel source contains the Atmel HLCDC DRM fix that calls __drm_atomic_helper_plane_destroy_state() from the relevant atomic_destroy_state cleanup path. Validate the running kernel version against the vendor advisory rather than relying only on the upstream version number, because distributions often backport fixes. On representative hardware, perform repeated display mode-setting or DRM atomic commit activity before and after patching and monitor slab memory, /proc/meminfo, slabtop, and dmesg for sustained growth or warnings. If kernel memory leak detection is available in a test environment, enable kmemleak and confirm that repeated graphics operations no longer produce unreferenced drm_crtc_commit-related objects or backtraces involving drm_atomic_helper_setup_commit. Also confirm that access controls on /dev/dri/* are limited to intended users and services.

Typical attack path

1. Gain local code execution on an affected Linux system or control of a local process with access to the DRM/KMS device interface.
2. Confirm that the system uses an affected kernel build and the Atmel HLCDC DRM driver path is present or enabled.
3. Repeatedly invoke graphics mode-setting or atomic display commit operations through DRM ioctls.
4. Cause the vulnerable atomic state destruction path to run repeatedly without freeing all associated DRM objects.
5. Accumulate unreleased kernel slab allocations over time.
6. Exhaust available memory or induce severe memory pressure, resulting in degraded performance, application failures, kernel OOM activity, hang, or reboot.

How to detect it

Look for evidence of local denial-of-service activity or prior triggering by reviewing kernel logs, system journals, OOM events, and memory telemetry on systems using Atmel HLCDC graphics. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, audit logs for access to /dev/dri/*, process accounting, endpoint telemetry, and embedded device watchdog or reboot logs. Indicators include steadily increasing slab memory during graphics activity, repeated DRM ioctl or mode-setting activity from an unusual local process, OOM killer messages following display operations, and kmemleak reports showing unreferenced objects with backtraces through drm_atomic_helper_setup_commit, drm_atomic_helper_commit, drm_atomic_commit, drm_mode_setcrtc, drm_ioctl, and sys_ioctl. Because this flaw is a memory leak rather than a code-execution vulnerability, there may be no durable file artifact or network indicator; absence of logs does not prove non-exploitation, especially on devices with limited log retention.

• atmel-hlcdc
• unreferenced object
• kmemleak_alloc
• drm_atomic_helper_setup_commit
• drm_atomic_helper_commit
• drm_atomic_commit
• drm_atomic_helper_set_config
• drm_mode_setcrtc
• drm_ioctl
• sys_ioctl
• /dev/dri/card0
• /dev/dri/renderD
• Out of memory: Killed process
• oom-killer
• slab memory increases
• drm_crtc_commit

What your security team should do

• Prioritize inventory of Linux systems and embedded devices that use Atmel HLCDC graphics hardware or ship kernels with the atmel-hlcdc DRM driver enabled.
• Patch affected systems using vendor-provided kernel updates or rebuilt kernels containing the upstream driver cleanup fix.
• For systems that cannot be patched quickly, restrict local shell access and limit membership in groups that can access DRM device nodes such as video or render.
• Review permissions on /dev/dri/* and ensure only trusted services and users can perform DRM/KMS operations.
• Monitor affected devices for unexplained slab memory growth, OOM killer activity, display stack instability, watchdog resets, or recurring reboots.
• Treat exploitation as a local denial-of-service risk rather than a remote code execution risk, but raise priority for shared devices, kiosks, embedded appliances, or systems running untrusted local workloads.
• In test or staging environments, use kmemleak or repeated DRM/KMS stress tests to verify that the patched kernel no longer leaks drm_crtc_commit-related objects.
• Because this is not listed in KEV, has no indicated ransomware use, and has very low EPSS, schedule remediation according to normal kernel maintenance unless the affected device class has high availability requirements.