Description

In the Linux kernel, the following vulnerability has been resolved: fbdev: clear fb_info->mode before deleting a videomode fb_set_var() can delete a mode from info->modelist when userspace passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code checks that the mode being deleted is not the current info->var and that fbcon is not using it, but it does not check fb_info->mode. fb_info->mode may still point into the modelist entry being deleted. If the entry is freed, later mode sysfs reads through show_mode() can dereference a stale pointer. Clear fb_info->mode before calling fb_delete_videomode() when it matches the mode being removed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:17:14.007Z",
  "pubdate": "2026-08-26T15:17:14.007Z",
  "executiveSummary": "A Use-After-Free (UAF) vulnerability exists within the Linux kernel fbdev subsystem, specifically concerning the management of videomode structures in the modelist.\nThe vulnerability arises when the fb_set_var() function facilitates the deletion of a videomode via the FBIOPUT_VSCREENINFO ioctl, without properly sanitizing the fb_info->mode pointer.\nThis flaw can be exploited by a local attacker to cause a kernel-level memory corruption or system crash through a subsequent read operation of the mode sysfs entry.\nAffected systems are Linux kernel environments where fbdev drivers are active. Successful exploitation requires the ability to trigger specific ioctl calls to modify the modelist while a stale pointer remains in the fb_info structure.\nThe primary risk is a local denial-of-service, though improper memory management in kernel space can potentially be leveraged for further privilege escalation depending on the system configuration and memory layout.",
  "technicalDetails": "The root cause of this vulnerability is a dangling pointer within the fb_info structure. In the Linux kernel's framebuffer (fbdev) implementation, the fb_info->modelist maintains a linked list of supported videomodes. When a user-space application invokes the FBIOPUT_VSCREENINFO ioctl with the FB_ACTIVATE_INV_MODE flag, the kernel triggers fb_set_var(), which proceeds to remove the specified videomode from the modelist.\nWhile the existing logic attempts to verify that the mode being deleted is not currently active in info->var and is not currently in use by fbcon, it fails to evaluate or nullify the fb_info->mode pointer. Consequently, fb_info->mode remains a reference to the memory address of the videomode entry that is about to be deallocated via fb_delete_videomode().\nThe attack flow follows a precise sequence: 1) An attacker identifies a videomode entry currently referenced by fb_info->mode; 2) The attacker invokes FBIOPUT_VSCREENINFO to delete that specific videomode; 3) The kernel frees the memory associated with that videomode; 4) The attacker subsequently triggers a sysfs read request targeting the mode entry. When show_mode() is invoked through the sysfs interface, it attempts to dereference the stale fb_info->mode pointer. Because the underlying memory has already been released to the kernel allocator, this results in a Use-After-Free condition.\nThis vulnerability is localized to the fbdev subsystem's handling of videomode lists. It does not require network exposure, but it does require local access to the system. Since the ioctl is accessible to any user with permission to open the framebuffer device node (typically /dev/fb*), the privilege requirement is effectively equivalent to the ability to interact with the device. Post-exploitation, the immediate impact is a kernel oops or kernel panic, causing a denial-of-service. If an attacker can spray the heap or reallocate the freed memory block before the dereference occurs, they might achieve arbitrary code execution or kernel memory disclosure, depending on the kernel's memory management state and protection mechanisms."
}