CVE-2026-46209

What it actually does

This is a local Linux kernel DRM/GEM memory-corruption flaw in framebuffer initialization. The vulnerable code calculates subsampled framebuffer plane dimensions with truncating integer division, while earlier ioctl validation rounds those dimensions up. For formats such as NV12 with very small or odd dimensions, the later GEM object size check can underflow and overflow, allowing an undersized graphics buffer to pass validation. When the GPU later accesses the incorrectly validated plane, it can read or write beyond the bounds of the GEM object, potentially causing kernel memory corruption, information disclosure, privilege escalation, or denial of service depending on the driver, GPU memory layout, and system hardening.

Why it matters to the business

An attacker who already has local access to a system and permission to use DRM graphics devices may be able to crash the host or potentially gain elevated privileges. This is most relevant for multi-user Linux workstations, VDI systems, shared GPU servers, desktop fleets, and container or virtualization platforms that expose GPU devices to untrusted workloads. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported public exploit maturity in the provided data, but the CVSS impact is high because successful exploitation can affect confidentiality, integrity, and availability at the kernel level.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user on a Linux system where access to DRM/KMS graphics device nodes is permitted. They create or obtain a small GEM buffer object and then issue framebuffer creation ioctls using a subsampled pixel format such as NV12 with edge-case dimensions, for example a one-pixel-tall framebuffer. Because the vulnerable DRM/GEM code truncates subsampled plane dimensions instead of rounding them up, the calculated plane height can become zero. A subsequent unsigned arithmetic expression underflows and wraps, producing an incorrectly small minimum-size requirement. The undersized GEM object is accepted as a valid framebuffer. When the framebuffer is used and the GPU accesses the affected chroma plane, the device can read or write past the object boundary. The practical outcome may be a GPU hang, kernel crash, disclosure of adjacent memory, or memory corruption that could be shaped into privilege escalation on susceptible systems.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the DRM/GEM fix for drm_gem_fb_init_with_funcs() using drm_format_info_plane_width() and drm_format_info_plane_height() instead of open-coded integer division. No exact fixed kernel versions were provided in the input, so use vendor advisories, kernel changelogs, and package metadata to identify the first fixed build for each distribution. Prioritize systems that allow local interactive users, shared development hosts, GPU-accelerated workloads, VDI, desktop environments, and containers or virtual machines with direct GPU device exposure. Where immediate patching is not possible, restrict access to DRM/KMS device nodes, remove untrusted users from graphics-related device groups where feasible, avoid passing /dev/dri devices into untrusted containers, use cgroup device policies to deny unnecessary GPU device access, consider ioctl filtering for high-risk sandboxed workloads, and keep IOMMU/VT-d protections enabled where supported. Reboot into the fixed kernel after installation; merely installing the package is insufficient if the old kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build containing the DRM/GEM framebuffer dimension-calculation fix. Validate with uname or package tooling after reboot and compare against the distribution advisory or changelog. Review kernel source or vendor patch notes for the change replacing open-coded width/height division in drm_gem_fb_init_with_funcs() with drm_format_info_plane_width() and drm_format_info_plane_height(). In a controlled non-production test environment, a regression test that attempts to create an undersized GEM framebuffer using a subsampled format and edge-case dimensions should be rejected after the fix rather than accepted. Also verify mitigations by checking permissions on /dev/dri/card* and /dev/dri/renderD*, container device passthrough settings, and membership in graphics-related groups.

Typical attack path

1. Gain local execution on a Linux system with access to DRM graphics device nodes such as KMS/card devices.
2. Open the relevant DRM device and create or reference a small GEM buffer object.
3. Submit framebuffer creation requests using a subsampled pixel format and dimensions that trigger the inconsistent rounding behavior, such as NV12 with a one-pixel or otherwise non-even plane dimension.
4. Cause the vulnerable GEM framebuffer size validation to accept an undersized object.
5. Trigger GPU access to the malformed framebuffer so the GPU reads or writes beyond the GEM object bounds.
6. Leverage the resulting out-of-bounds access for denial of service, information disclosure, or possible kernel-level privilege escalation depending on the driver and platform.

How to detect it

There is no reliable network indicator for this issue because exploitation is local through Linux DRM/GEM graphics ioctls. To assess possible prior exploitation, review kernel logs, persistent journal entries, crash dumps, and GPU driver logs for GPU hangs, DRM errors, kernel oopses, or page faults occurring near framebuffer creation activity. Correlate these events with auditd, process accounting, eBPF, or endpoint telemetry showing processes opening /dev/dri/card* or /dev/dri/renderD* and issuing DRM mode-setting or framebuffer-related ioctls. Pay particular attention to crashes or GPU faults from untrusted user sessions, containers, browser GPU processes, media-processing tools, test programs, or unfamiliar binaries. If available, inspect kernel crash dumps for stacks involving DRM framebuffer, GEM framebuffer, KMS, or driver-specific framebuffer paths. Because the vulnerability does not define a unique file, command, registry key, or network signature, detections should focus on anomalous local GPU device use followed by DRM/GPU faults or kernel instability.

What your security team should do

• Inventory Linux systems with GPUs or DRM devices exposed, especially shared workstations, VDI hosts, GPU compute nodes, and container hosts that pass through /dev/dri devices.
• Patch and reboot affected systems using vendor kernel updates that include the DRM/GEM framebuffer fix.
• Prioritize systems with untrusted local users or untrusted GPU-enabled workloads, because exploitation requires local access and graphics device permissions.
• Temporarily restrict access to DRM/KMS device nodes and remove unnecessary GPU device passthrough from containers or sandboxes until patching is complete.
• Review device-node permissions and group membership for graphics access, including video, render, or distribution-specific equivalents.
• Monitor kernel, DRM, and GPU driver logs for unexplained GPU faults, hangs, oopses, or crashes involving framebuffer creation or GEM objects.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, audit logs, and details of processes that had /dev/dri devices open at the time.
• Track vendor advisories for exact fixed kernel package versions because fixed versions were not supplied in the source data.