CVE-2026-46209

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs()<br /> <br /> drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions<br /> using plain integer division:<br /> <br /> unsigned int width = mode_cmd-&gt;width / (i ? info-&gt;hsub : 1);<br /> unsigned int height = mode_cmd-&gt;height / (i ? info-&gt;vsub : 1);<br /> <br /> However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses<br /> drm_format_info_plane_width/height() which round up dimensions via<br /> DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object<br /> size check for certain pixel format and dimension combinations.<br /> <br /> For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the<br /> GEM size validation path sees height=0 instead of height=1. The<br /> expression (height - 1) then wraps to UINT_MAX as an unsigned int,<br /> causing min_size to overflow and wrap back to a small value. A tiny<br /> GEM object therefore passes the size guard, yet when the GPU accesses<br /> the chroma plane it will read or write memory beyond the object&amp;#39;s<br /> bounds.<br /> <br /> Fix by replacing the open-coded divisions with drm_format_info_plane_width()<br /> and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match<br /> the calculation already used in framebuffer_check().