CVE-2026-43236

What it actually does

CVE-2026-43236 is a local Linux kernel use-after-free in the Atmel HLCDC DRM driver. The plane state duplication path copies an Atmel-specific plane state structure without correctly duplicating the embedded drm_plane_state, leaving state->commit pointing to an old drm_crtc_commit object. During a later drm_atomic_commit() sequence, the kernel may dereference or modify a commit object that has already been freed, causing slab memory corruption. Depending on kernel configuration, allocator behavior, and attacker control over heap layout, impact can range from kernel crash and denial of service to potential local privilege escalation or kernel-mode code execution. The flaw requires local access and privileges sufficient to interact with the affected DRM device node; it is not remotely exploitable by itself. Exploit maturity is currently listed as none, EPSS is very low and flat, and it is not listed in CISA KEV.

Why it matters to the business

Systems using Linux kernels with the affected Atmel HLCDC display controller driver may be vulnerable to local kernel compromise or crashes. The most likely operational impact is instability or device outage on embedded, industrial, appliance, or ARM-based systems that expose the DRM device to local users or applications. In multi-user or kiosk-like environments, a lower-privileged local account or compromised application with graphics device access could potentially escalate privileges. Current public exploitation signals are low, but kernel memory corruption vulnerabilities should still be prioritized on exposed multi-user systems and production devices where availability and device integrity are important.

How an attack unfolds

An attacker first needs local code execution on a system that is running an affected Linux kernel and using the atmel-hlcdc DRM driver. The attacker must be able to open and issue ioctls against the DRM device, commonly through /dev/dri/card* or related graphics interfaces. By manipulating DRM state transitions, such as closing and re-opening the device node while another DRM client such as fbdev remains attached, the attacker can trigger a flawed plane-state duplication path. The duplicated state retains a stale commit pointer from an older state. A subsequent atomic commit causes the kernel to operate on the previously freed drm_crtc_commit object, corrupting kernel heap memory. A simple exploit may only crash the kernel, while a more advanced exploit would attempt to shape slab allocations so the stale pointer references attacker-influenced memory, potentially enabling privilege escalation.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the atmel-hlcdc DRM fix for this issue. The corrected code uses __drm_atomic_helper_duplicate_plane_state() so that the base drm_plane_state, including the commit pointer, is duplicated safely. No exact fixed package versions were provided, so use the latest stable kernel or distribution/vendor security update that references this fix. Where immediate patching is not possible, reduce exposure by restricting access to DRM and framebuffer device nodes to trusted users only, removing untrusted users from graphics-related groups, disabling or blacklisting the atmel-hlcdc driver if the hardware/display function is not required, and limiting local shell or application access on affected devices. Reboot after kernel updates or driver changes to ensure the vulnerable code is no longer running.

How to confirm the fix worked

Confirm the running kernel has been updated using uname -r and the relevant distribution or vendor package metadata. Review kernel changelogs or source patches for the atmel-hlcdc change that replaces raw structure copying with __drm_atomic_helper_duplicate_plane_state() in atmel_hlcdc_plane_atomic_duplicate_state(). On source-based or custom kernels, inspect the driver code under the DRM Atmel HLCDC implementation and verify the fixed helper is used. Validate that the affected driver is not loaded if mitigation relies on disabling it. Check permissions on /dev/dri/* and framebuffer device nodes to ensure only trusted users or service accounts have access. If feasible in a test environment, run graphics/DRM regression tests with KASAN, SLUB poisoning, or other kernel memory debugging enabled and confirm that closing and re-opening the DRM device while fbdev or another DRM client is attached no longer produces use-after-free, slab poison, or kernel oops messages.

Typical attack path

1. Obtain local code execution on a Linux system using the Atmel HLCDC DRM driver.
2. Confirm access to the affected graphics device node, such as /dev/dri/card* or a related framebuffer/DRM interface.
3. Trigger DRM plane state duplication and atomic commit activity through DRM ioctls or graphics stack interactions.
4. Close and re-open the DRM device while another DRM client, such as fbdev, remains attached to create the stale commit-pointer condition.
5. Cause a subsequent drm_atomic_commit() path to use the freed drm_crtc_commit object.
6. Leverage the resulting kernel heap corruption to crash the system or attempt local privilege escalation.

How to detect it

Look for evidence of attempted or successful triggering in kernel logs, crash dumps, persistent pstore logs, system journals, and endpoint telemetry around graphics device access. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /sys/fs/pstore/, vmcore/kdump artifacts, auditd records for access to /dev/dri/*, and EDR telemetry showing unusual local processes interacting with DRM or framebuffer devices. Focus on kernel warnings or crashes mentioning atmel_hlcdc, drm_atomic_commit, drm_crtc_commit, drm_atomic_helper_setup_commit, drm_atomic_helper_commit_hw_done, drm_mode_setcrtc, drm_framebuffer_remove, SLUB poison corruption, KASAN use-after-free, or BUG/Oops messages shortly after a process opened, closed, or issued ioctls to a DRM device. Because no public exploit indicators or named threat actors are currently associated with this vulnerability, detection should emphasize behavioral and forensic artifacts rather than fixed malware signatures. Correlate suspicious graphics device activity from unexpected users or services with kernel memory-corruption messages and unplanned reboots.

• BUG kmalloc-64 (Not tainted): Poison overwritten
• Poison overwritten
• First byte 0x6a instead of 0x6b
• FIX kmalloc-64: Restoring Poison
• Allocated in drm_atomic_helper_setup_commit
• Freed in drm_atomic_helper_commit_hw_done
• drm_atomic_helper_setup_commit
• drm_atomic_helper_commit_hw_done
• drm_atomic_helper_commit_tail
• drm_atomic_helper_commit
• drm_atomic_commit
• drm_framebuffer_remove
• drm_mode_rmfb_work_fn
• drm_atomic_helper_set_config
• drm_mode_setcrtc
• drm_ioctl
• atmel_hlcdc_plane_atomic_duplicate_state
• atmel-hlcdc
• drm_crtc_commit
• /dev/dri/card
• /dev/dri/renderD
• /dev/fb0
• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• kernel BUG at drivers/gpu/drm
• Oops:
• general protection fault

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and ARM platforms that use the Atmel HLCDC DRM driver.
• Prioritize patching systems where untrusted users, containers, kiosk applications, browsers, or third-party workloads can access local graphics devices.
• Apply the latest vendor-supported kernel update that includes the atmel-hlcdc DRM plane-state duplication fix, then reboot.
• If patching is delayed, restrict /dev/dri/* and framebuffer device access to trusted users and remove unnecessary users from video, render, or equivalent graphics-access groups.
• Disable or blacklist the atmel-hlcdc driver on systems where the hardware/display path is not required.
• Monitor kernel logs for DRM, slab poisoning, KASAN, use-after-free, or oops messages involving atmel_hlcdc, drm_atomic_commit, or drm_crtc_commit.
• Treat unexplained local kernel crashes on affected systems as potentially security-relevant until logs and crash dumps are reviewed.
• Track vendor advisories because exact fixed package versions may vary across Linux distributions and embedded board support packages.