CVE-2026-46209 Overview
CVE-2026-46209 is a Linux kernel vulnerability in the Direct Rendering Manager (DRM) Graphics Execution Manager (GEM) framebuffer subsystem. The flaw resides in drm_gem_fb_init_with_funcs(), which calculates sub-sampled plane dimensions using plain integer division instead of DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for specific pixel format and dimension combinations. An attacker who can submit crafted framebuffer parameters can trigger an integer underflow, allowing a small GEM object to pass size validation while the GPU later accesses memory beyond the object's bounds.
Critical Impact
The size-check bypass enables out-of-bounds memory access by the GPU when processing chroma planes, leading to potential kernel memory corruption or information disclosure.
Affected Products
- Linux kernel (DRM GEM framebuffer subsystem)
- Distributions shipping vulnerable drm_gem_fb_init_with_funcs() implementations
- Systems using sub-sampled pixel formats such as NV12
Discovery Timeline
- 2026-05-28 - CVE-2026-46209 published to NVD
- 2026-05-28 - Last updated in NVD database
Technical Details for CVE-2026-46209
Vulnerability Analysis
The vulnerability stems from inconsistent arithmetic between two code paths that validate framebuffer dimensions. drm_gem_fb_init_with_funcs() computes sub-sampled plane width and height using plain integer division:
unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width() and drm_format_info_plane_height(), which round dimensions up via DIV_ROUND_UP(). The two functions disagree for dimensions that do not divide evenly by the sub-sampling factor.
Root Cause
For NV12 format with a vertical sub-sampling factor (vsub=2) and a 1-pixel-tall framebuffer, the GEM size validation path computes height = 1 / 2 = 0 instead of the expected rounded-up value of 1. The expression (height - 1) then wraps to UINT_MAX as an unsigned integer. This causes min_size to overflow and wrap back to a small value. A tiny GEM object therefore satisfies the size guard despite being insufficient to back the chroma plane.
Attack Vector
A local user with access to the DRM device node can submit a crafted DRM_IOCTL_MODE_ADDFB2 request specifying a sub-sampled pixel format combined with a non-aligned dimension. When the kernel subsequently programs the GPU to access the under-allocated chroma plane, the hardware reads or writes memory beyond the GEM object's allocation. The fix replaces the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), aligning the calculations with framebuffer_check().
Detection Methods for CVE-2026-46209
Indicators of Compromise
- Unexpected GPU faults, page faults, or DMA errors logged in dmesg referencing DRM or GEM subsystems
- Kernel oops or KASAN reports involving drm_gem_fb_init_with_funcs or related framebuffer paths
- Unprivileged processes repeatedly issuing DRM_IOCTL_MODE_ADDFB2 with unusual format and dimension combinations
Detection Strategies
- Audit kernel build versions across the fleet to identify hosts running pre-patch drm_gem_fb code
- Enable kernel address sanitizer (KASAN) or KFENCE in test environments to surface out-of-bounds GEM access
- Review auditd records for ioctl calls against /dev/dri/card* from non-graphical user accounts
Monitoring Recommendations
- Forward kernel ring buffer events to a centralized log platform and alert on DRM and GPU fault patterns
- Track package and kernel update status across Linux endpoints to confirm patch deployment
- Correlate process telemetry with DRM device access to detect anomalous use of the graphics stack
How to Mitigate CVE-2026-46209
Immediate Actions Required
- Apply the upstream Linux kernel patches that replace the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height()
- Update to a distribution kernel that incorporates the stable backport for your release branch
- Restrict access to /dev/dri/* device nodes to trusted user groups where graphics access is not required
Patch Information
The fix has been merged into the mainline Linux kernel and backported to stable branches. Refer to the upstream commits: Kernel.org Commit 1a17ea98, Kernel.org Commit 1da4ab71, Kernel.org Commit 3d4c2268, Kernel.org Commit 6b992591, and Kernel.org Commit c5fc49d8.
Workarounds
- Tighten permissions on DRM device nodes to limit ioctl access to trusted accounts and services
- Disable or unload graphics drivers on headless servers where DRM functionality is not required
- Apply mandatory access control profiles (SELinux, AppArmor) to restrict which processes can call DRM ioctls
# Verify running kernel version and DRM device permissions
uname -r
ls -l /dev/dri/
# Restrict DRM device access to the video group only
chgrp video /dev/dri/card*
chmod 0660 /dev/dri/card*
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


