# CVE-2026-43269: drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback

> A memory leak in the Atmel HLCDC DRM driver allows attackers to exhaust kernel memory, causing system instability or denial of service.

- **Severity:** Medium 5.5 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 6 May 2026
- **Updated:** 11 May 2026
- **Also known as:** BELL-CVE-2026-43269, DEBIAN-CVE-2026-43269, GHSA-9729-xjvh-4qp8, ROOT-OS-DEBIAN-11-CVE-2026-43269, ROOT-OS-UBUNTU-2204-CVE-2026-43269, ROOT-OS-UBUNTU-2404-CVE-2026-43269, UBUNTU-CVE-2026-43269

## What is CVE-2026-43269?

CVE-2026-43269 is a medium-severity denial of service vulnerability in Linux kernel, published on 6 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback

After several commits, the slab memory increases. Some drm_crtc_commit
objects are not freed. The atomic_destroy_state callback only put the
framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function
to put all the objects that are no longer needed.

It has been seen after hours of usage of a graphics application or using
kmemleak:

unreferenced object 0xc63a6580 (size 64):
  comm "egt_basic", pid 171, jiffies 4294940784
  hex dump (first 32 bytes):
    40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6  @P4..........e:.
    8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6  .e:......e:..e:.
  backtrace (crc c25aa925):
    kmemleak_alloc+0x34/0x3c
    __kmalloc_cache_noprof+0x150/0x1a4
    drm_atomic_helper_setup_commit+0x1e8/0x7bc
    drm_atomic_helper_commit+0x3c/0x15c
    drm_atomic_commit+0xc0/0xf4
    drm_atomic_helper_set_config+0x84/0xb8
    drm_mode_setcrtc+0x32c/0x810
    drm_ioctl+0x20c/0x488
    sys_ioctl+0x14c/0xc20
    ret_fast_syscall+0x0/0x54

Weakness: CWE-401 (Missing Release of Memory after Effective Lifetime)

## Which versions are affected by CVE-2026-43269?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2026-43269?

Apply the vendor's patch.

## Is CVE-2026-43269 being exploited?

There is no known exploitation of CVE-2026-43269 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-43269 and fix it if it is affected.

What it is: CVE-2026-43269 is a medium-severity denial of service vulnerability in Linux kernel, published on 6 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-43269 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-43269/ (Markdown: https://insights.sbomify.com/CVE-2026-43269/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-43269
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-43269
- OSV: https://osv.dev/vulnerability/CVE-2026-43269

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-43269/
Summaries are generated and may contain mistakes; the official description above is the record.