Linux Kernel fbdev EUVD-2026-66494

Exploitation requires: (1) a local shell account on the target system with read-write access to the framebuffer device node (/dev/fb0 or similar), which typically requires membership in the 'video' group or equivalent; (2) the fbdev subsystem must be loaded and an active framebuffer device present - this excludes pure DRM/KMS systems without legacy fbdev emulation, headless servers, and most container environments; (3) the attacker must issue FBIOPUT_VSCREENINFO with FB_ACTIVATE_INV_MODE targeting a videomode that currently matches fb_info->mode (the mode must be present in the modelist and set as the cached mode pointer); (4) a sysfs read of the framebuffer mode attribute must occur after the deletion, either by the attacker or via a race with another process. Exploitation is limited by the requirement for local authenticated access and the presence of an active framebuffer device, excluding the large majority of cloud, container, and headless server deployments.

The CVSS 3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately reflects the local exploitation vector with low attack complexity and low-privilege requirement. The high C/I/A scores are consistent with a kernel use-after-free: at minimum the primitive enables reading freed kernel memory (information disclosure), and depending on heap layout, it may allow controlled writes enabling privilege escalation or kernel panic. The 'Information Disclosure' tag in the input understates the potential impact indicated by the full CVSS vector. No EPSS score was provided, which limits probabilistic risk quantification. The vulnerability is not in CISA KEV and no public proof-of-concept code has been identified, meaning opportunistic exploitation at scale is not currently a concern. Real-world risk is moderated by several factors: exploitation requires a local shell account on a system with a framebuffer device exposed, the fbdev subsystem is increasingly deprecated in favor of DRM/KMS and may be absent on server or containerized workloads, and the race window for heap exploitation is nondeterministic. However, for embedded Linux, kiosk, or legacy graphics workloads where fbdev remains active and multi-user access exists, the risk is meaningful.

A local user with a standard shell account on a Linux system exposing /dev/fb0 opens the framebuffer device and issues an FBIOPUT_VSCREENINFO ioctl call with FB_ACTIVATE_INV_MODE set, specifying a videomode that matches the currently cached fb_info->mode pointer. The kernel deletes the modelist entry and frees the associated memory without clearing the stale fb_info->mode reference. The attacker then triggers a sysfs read of /sys/class/graphics/fb0/mode, causing show_mode() to dereference the freed memory - leaking kernel heap content or, under favorable heap conditions, redirecting execution to attacker-controlled data. No public proof-of-concept code has been identified at time of analysis.