CVE-2026-43287: Linux Kernel Privilege Escalation Flaw

CVE-2026-43287 Overview

CVE-2026-43287 is a Linux kernel vulnerability in the Direct Rendering Manager (DRM) subsystem. The DRM_IOCTL_MODE_CREATEPROPBLOB ioctl lets userspace allocate arbitrary-sized property blobs backed by kernel memory. The kernel did not charge those allocations to the calling process's memory cgroup (memcg). Unprivileged local users can therefore trigger unbounded kernel memory consumption and potentially cause a system-wide out-of-memory (OOM) condition. The flaw is classified as a missing-release/memory-management defect [CWE-401] and affects multiple Linux kernel branches including 7.0 release candidates.

Critical Impact

Local unprivileged users can exhaust kernel memory through repeated DRM property blob allocations, leading to denial of service on shared multi-tenant Linux systems.

Affected Products

• Linux kernel (multiple stable branches)
• Linux kernel 7.0-rc1 through 7.0-rc7
• Systems exposing /dev/dri/* to unprivileged users (desktops, containers, VMs)

Discovery Timeline

• 2026-05-08 - CVE-2026-43287 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43287

Vulnerability Analysis

The DRM subsystem exposes DRM_IOCTL_MODE_CREATEPROPBLOB, which userspace uses to attach arbitrary blob data to display mode properties. Each invocation allocates a kernel buffer sized by the caller. Prior to the fix, the allocation used a GFP_KERNEL flag without the __GFP_ACCOUNT bit. Kernel memory consumed by the blob was not attributed to the calling task's memory cgroup.

Without memcg accounting, container memory limits and cgroup-v2 memory.max controls do not cap the total amount of kernel memory a process can request through this path. A local attacker can issue repeated ioctls with large blob sizes until the host's available kernel memory is exhausted. The kernel OOM killer then targets victim processes across the system rather than the offending container.

Root Cause

The root cause is missing memcg accounting on a userspace-driven kernel allocation [CWE-401]. The fix marks the property blob data allocation with GFP_KERNEL_ACCOUNT so the memory is charged to the caller's cgroup. Existing cgroup memory limits then apply, bounding consumption without introducing new policy or per-file limits.

Attack Vector

Exploitation requires local access and permission to open a DRM render or primary node, typically /dev/dri/card0 or /dev/dri/renderD128. The attacker repeatedly calls DRM_IOCTL_MODE_CREATEPROPBLOB with large length values and retains the returned blob identifiers. Each successful call commits unaccounted kernel memory. Containerized workloads that pass DRM devices into guests are particularly exposed because the host cannot enforce per-container ceilings on this allocation path.

No synthetic exploit code is reproduced here. The upstream patches referenced below in Kernel Git Commit cb8b9a1 and related commits show the one-line allocation flag change.

Detection Methods for CVE-2026-43287

Indicators of Compromise

• Sudden growth of unreclaimable kernel slab memory without corresponding RSS growth in user processes.
• High rate of DRM_IOCTL_MODE_CREATEPROPBLOB calls from a single PID or container, visible via strace or audit subsystem logs.
• Kernel OOM-killer events targeting unrelated processes while a low-privilege workload remains alive.

Detection Strategies

• Enable Linux audit rules on the ioctl syscall filtered by DRM device file descriptors to flag high-volume property blob creation.
• Monitor /proc/meminfoSlab and SUnreclaim counters along with cgroup memory.kmem.usage_in_bytes for anomalous growth.
• Correlate kernel ring buffer dmesg OOM messages with container and process telemetry to identify the offending workload.

Monitoring Recommendations

• Alert on processes opening /dev/dri/* from container runtimes that should not require GPU access.
• Track kernel memory pressure metrics per cgroup and trigger investigation when kmem growth diverges from user memory growth.
• Retain syscall and process telemetry centrally so resource-exhaustion patterns can be reconstructed after an OOM event.

How to Mitigate CVE-2026-43287

Immediate Actions Required

• Apply the upstream stable kernel patches that add GFP_KERNEL_ACCOUNT to DRM property blob allocations.
• Inventory hosts exposing /dev/dri/* to unprivileged users or containers and prioritize them for patching.
• Set or tighten cgroup v2 memory.max and memory.swap.max limits on workloads with DRM access so post-patch accounting is enforceable.

Patch Information

Fixes are available in the stable trees referenced by the Linux kernel maintainers. See Kernel Git Commit 26b4309, Kernel Git Commit 405fd65, Kernel Git Commit 815fa29, Kernel Git Commit 866e0c1, Kernel Git Commit 8e1664b, Kernel Git Commit b611721, Kernel Git Commit bbfaa57, and Kernel Git Commit cb8b9a1. Rebuild and reboot into a patched kernel image to enable the fix.

Workarounds

• Restrict access to /dev/dri/* nodes by tightening group membership (typically video and render) and removing unneeded users.
• Avoid passing DRM device nodes into untrusted containers; if GPU access is required, isolate workloads on dedicated hosts.
• Use seccomp profiles that deny the ioctl syscall or filter on the DRM_IOCTL_MODE_CREATEPROPBLOB request number for workloads that do not need property blob creation.

# Configuration example: limit DRM access and cap container kernel memory
# 1. Remove unprivileged users from render/video groups
sudo gpasswd -d untrusted_user render
sudo gpasswd -d untrusted_user video

# 2. Enforce cgroup v2 memory ceilings on container workloads
# (systemd-run example)
sudo systemd-run --scope \
  -p MemoryMax=2G \
  -p MemorySwapMax=0 \
  --uid=untrusted_user \
  /usr/bin/workload

# 3. Verify running kernel includes the fix
uname -r