PatchSiren cyber security CVE debrief
CVE-2026-46209 Linux CVE debrief
A vulnerability in the Linux kernel's Direct Rendering Manager (DRM) subsystem allows an attacker to bypass GEM object size validation, potentially leading to out-of-bounds memory access on the GPU. The root cause is an inconsistency between how plane dimensions are calculated in drm_gem_fb_init_with_funcs() (using plain integer division) versus framebuffer_check() (using DIV_ROUND_UP rounding). For certain pixel formats like NV12 with small dimensions, this causes integer underflow in size calculations, allowing undersized GEM objects to pass validation while the GPU accesses memory beyond the object's bounds.
- Vendor
- Linux
- Product
- Unknown
- CVSS
- HIGH 7.8
- CISA KEV
- Not listed in stored evidence
- Original CVE published
- 2026-05-28
- Original CVE updated
- 2026-05-30
- Advisory published
- 2026-05-28
- Advisory updated
- 2026-05-30
Who should care
Linux system administrators running GPU-enabled systems, particularly those handling video processing with YUV formats; security teams monitoring kernel vulnerabilities; developers of DRM/KMS drivers; organizations using Linux-based graphics workstations, media servers, or embedded systems with GPU acceleration
Technical summary
The vulnerability exists in drm_gem_fb_init_with_funcs() which computes sub-sampled plane dimensions using plain integer division (width / hsub, height / vsub), while the ioctl-level framebuffer_check() uses DIV_ROUND_UP() via drm_format_info_plane_width/height(). This inconsistency corrupts GEM object size validation. For example, with NV12 format (vsub=2) and a 1-pixel-tall framebuffer, the height calculation yields 0 instead of 1. The expression (height - 1) then underflows to UINT_MAX, causing min_size to overflow and wrap to a small value. This allows a tiny GEM object to pass size guards, but the GPU will access memory beyond the object's bounds when processing the chroma plane. The fix replaces open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height() to match the rounding behavior used in framebuffer_check().
Defensive priority
high
Recommended defensive actions
- Apply kernel patches from stable kernel git repositories when available for your distribution
- Audit systems using GPU drivers that rely on DRM GEM framebuffer functionality, particularly those processing video with NV12 or other sub-sampled YUV formats
- Monitor kernel security advisories from your Linux distribution for backported fixes
- Consider restricting unprivileged user access to DRM/GPU devices where feasible
- Review application and service configurations that allow user-controlled framebuffer dimensions
Evidence notes
The vulnerability description indicates this is a kernel-level DRM/GEM framebuffer initialization bug with a clear fix pattern: replacing open-coded division with drm_format_info_plane_width/height() functions. Multiple stable kernel commits are referenced, suggesting backports to various kernel versions. The issue affects sub-sampled pixel formats (e.g., NV12 with vsub=2) and manifests when framebuffer dimensions result in fractional plane sizes that truncate to zero instead of rounding up.
Official resources
-
CVE-2026-46209 CVE record
CVE.org
-
CVE-2026-46209 NVD detail
NVD
-
Source item URL
nvd_modified
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
2026-05-28