CVE-2026-43287

What it actually does

This is a local denial-of-service flaw in the Linux kernel Direct Rendering Manager subsystem. A low-privileged local user that can open a DRM device can repeatedly invoke DRM_IOCTL_MODE_CREATEPROPBLOB to allocate arbitrarily sized DRM property blobs in kernel memory. Before the fix, the backing allocation was not charged to the caller's memory cgroup, so cgroup memory limits did not constrain the kernel memory growth. This can lead to system-wide memory exhaustion, OOM kills, severe performance degradation, or a host crash. The fix accounts the allocation with GFP_KERNEL_ACCOUNT so existing memory cgroup limits apply.

Why it matters to the business

An attacker or compromised low-privileged account on a Linux system could intentionally exhaust kernel memory and disrupt workloads on the entire host, including unrelated services or containers. The risk is most relevant on multi-user systems, shared GPU/desktop hosts, CI workers, container hosts exposing DRM devices, and environments where untrusted code can access /dev/dri devices. The issue has a low EPSS score and is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, the operational impact can be high where local code execution is already possible.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a vulnerable Linux system. They identify accessible DRM device nodes, typically under /dev/dri/, and open a device that accepts mode-setting DRM ioctls. The attacker then runs a loop that submits DRM_IOCTL_MODE_CREATEPROPBLOB requests with large blob sizes or many repeated allocations. Because the vulnerable kernel does not charge the blob data allocation to the attacker's memory cgroup, normal cgroup memory limits may not stop the growth. Kernel memory consumption rises until the system invokes the OOM killer, kills unrelated processes, becomes unstable, or crashes. Successful exploitation does not provide code execution or data theft by itself, but it can be used to disrupt service availability or as part of a broader intrusion to cover activity or degrade monitoring.

How to fix it

Apply a Linux kernel update from the distribution or kernel vendor that includes the DRM fix to account property blob allocations to memory cgroups, commonly associated with the upstream change titled "drm: Account property blob allocations to memcg". Because no exact fixed versions were provided, use vendor advisories and package changelogs to identify the first corrected kernel build for each supported distribution. Reboot into the patched kernel after installation; updating the package alone is not sufficient if the running kernel remains vulnerable. As temporary mitigations, restrict access to DRM device nodes to trusted users only, avoid exposing /dev/dri devices to untrusted containers, remove unnecessary GPU/device passthrough, enforce least-privilege group membership for video/render-related groups, and use host-level monitoring or resource isolation to detect abnormal kernel memory pressure. These mitigations reduce exposure but do not fully correct the accounting bug.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, contains the fix. Validate through vendor package metadata, kernel changelogs, or source inspection showing DRM property blob data allocations are performed with GFP_KERNEL_ACCOUNT or equivalent memcg-accounted allocation behavior. On Linux systems, compare `uname -r` against the vendor-fixed kernel version and verify the host has been rebooted into that kernel. Review permissions on /dev/dri/card* and /dev/dri/renderD* and confirm untrusted users or containers do not have unnecessary access. Where safe in a controlled test environment, exercise DRM property blob creation inside a memory-limited cgroup and confirm memory consumption is charged and constrained rather than causing unbounded host-wide kernel memory growth.

Typical attack path

1. Gain local code execution as a low-privileged user, through login access, a compromised service account, a container workload, or another vulnerability.
2. Check for accessible DRM device nodes such as /dev/dri/card0 or other /dev/dri/card* entries.
3. Open an accessible DRM device file from user space.
4. Repeatedly call DRM_IOCTL_MODE_CREATEPROPBLOB with large property blob allocations.
5. Bypass effective cgroup memory containment because the vulnerable allocation is not charged to the caller's memory cgroup.
6. Drive kernel memory pressure until OOM killer activity, service termination, system instability, or host crash occurs.

How to detect it

Look for evidence of prior local denial-of-service activity rather than remote network indicators. Relevant sources include kernel logs, system journal entries, auditd logs, endpoint telemetry, process accounting, container runtime logs, and crash dumps. Search for OOM killer events, host-wide memory exhaustion, unexplained termination of unrelated services, kernel panics, or repeated instability coinciding with activity from low-privileged users or containers that accessed /dev/dri devices. If auditd or eBPF telemetry is available, review ioctl-heavy processes opening /dev/dri/card* and issuing DRM mode-setting calls, especially processes that are short-lived, unrecognized, or launched from temporary directories. In container environments, correlate host OOM events with containers that had GPU or DRM device passthrough. Absence of specific logs does not prove absence of exploitation, because the exploit may only leave generic memory-pressure and OOM artifacts unless device access or ioctl activity was being audited.

• DRM_IOCTL_MODE_CREATEPROPBLOB
• /dev/dri/card
• /dev/dri/renderD
• Out of memory: Killed process
• invoked oom-killer
• oom-kill:constraint=CONSTRAINT_NONE
• oom-kill:constraint=CONSTRAINT_MEMCG
• Memory cgroup out of memory
• Kernel panic - not syncing: System is deadlocked on memory
• drm_mode_createblob_ioctl
• CREATEPROPBLOB

What your security team should do

• Prioritize patching shared Linux hosts, container platforms, VDI/desktop systems, GPU-enabled servers, CI runners, and multi-user systems where untrusted users or workloads can access /dev/dri devices.
• Inventory systems exposing DRM devices and identify users, groups, containers, or services with access to /dev/dri/card* and /dev/dri/renderD*.
• Apply vendor kernel updates containing the DRM memcg accounting fix and reboot systems into the corrected kernel.
• Temporarily remove unnecessary DRM/GPU device access from untrusted containers and workloads until patched.
• Tighten membership in video, render, or distribution-specific device access groups to only trusted accounts.
• Monitor for OOM killer events, sudden kernel memory growth, repeated crashes, or abnormal ioctl activity against /dev/dri devices.
• Treat unexpected local DoS activity as a potential sign of broader compromise and investigate the account, container, or process responsible.
• Because this issue is not in CISA KEV and has low EPSS, schedule broad fleet remediation through normal kernel patch cycles, but accelerate remediation for exposed multi-tenant or untrusted-code environments.