CVE-2026-46209

drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs()

HIGH
7.8
CVSS Score
Published: May 28, 2026 at 09:40 AM UTC
Updated: October 19, 2026 at 08:18 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.1%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions 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/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.14 ≤ v < 5.10.2585.11 ≤ v < 5.15.2095.16 ≤ v < 6.1.1756.13 ≤ v < 6.18.326.19 ≤ v < 7.0.96.2 ≤ v < 6.6.1406.7 ≤ v < 6.12.904c3dbb2c312c9fafbac30d98c523b8b1f3455d787.17.1 rc1
Vendor states this is fixed in 11427ad6c9f0def5ce567982b785da3191946430 (fixed)
Vendor states this is fixed in 1a17ea9861e89585361caa8bc231bd22dc6dbe7d (fixed)
Vendor states this is fixed in 1da4ab7189f1064b3b712b388772c008b4d82580 (fixed)
Vendor states this is fixed in 22922f7dae74409fc4bf0f1142710cb6b8ce8cc2 (fixed)
Vendor states this is fixed in 3d4c2268bd7243c3780fe32bf24ff876da272acf (fixed)
Vendor states this is fixed in 6b992591e04f2cce813bcf239b354f375bbf84d3 (fixed)
Vendor states this is fixed in adfc5ba4ef4dd2bca5969f40e8fc7b41fb3902ad (fixed)
Vendor states this is fixed in c5fc49d8470c5ebf3b41607600f277158f159950 (fixed)
Vendor states this is fixed in 4.14 (unaffected)
Vendor states this is fixed in 5.10.258 (unaffected)
Vendor states this is fixed in 5.15.209 (unaffected)
Vendor states this is fixed in 6.1.175 (unaffected)
Vendor states this is fixed in 6.12.90 (unaffected)
Vendor states this is fixed in 6.18.32 (unaffected)
Vendor states this is fixed in 6.6.140 (unaffected)
Vendor states this is fixed in 7.0.9 (unaffected)
Vendor states this is fixed in 7.1 (unaffected)

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-787CWE-190

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card