CVE-2026-97604 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
fbdev: vfb: defer cleanup until the last reference
FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace.
KASAN reports:
BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125
_copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114)
Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459)
Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489)
unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/25/2026
The virtual frame buffer driver in the Linux kernel contains a critical use-after-free vulnerability arising from improper resource management during device removal operations. This flaw specifically affects the handling of color map data when interacting with user-space applications through ioctl calls. The root cause lies in the timing mismatch between the lifecycle of the framebuffer device structure and the persistence of open file descriptors that reference it. When an application opens a frame buffer device, it obtains a reference to the underlying fb_info structure. However, upon driver unbind or removal via vfb_remove, the kernel immediately frees associated resources such as the colormap before ensuring that all user-space references have been fully released. This creates a race condition where memory allocated for internal kernel structures is reclaimed while still being actively accessed by concurrent processes.
The technical mechanism of exploitation involves the FBIOGETCMAP ioctl command, which retrieves color map information from the framebuffer device to userspace. During this operation, the driver takes a shallow snapshot of the info->cmap structure and subsequently drops the info lock before performing the user copy operation. This design choice is intended to reduce contention but introduces significant risk when combined with premature cleanup logic. If vfb_remove is invoked while an ioctl call is in progress or has just completed its data acquisition phase, the colormap memory may be deallocated by fb_dealloc_cmap within vfb_remove before _copy_to_user finishes writing the data to user space. This results in a slab-use-after-free condition where the kernel reads from freed memory, potentially leading to information disclosure of sensitive kernel data or system instability due to corrupted memory access patterns.
From an operational impact perspective, this vulnerability allows for local privilege escalation or denial of service attacks by unprivileged users who can open frame buffer devices and trigger concurrent removal events. The presence of KASAN reports indicating reads from freed slab objects confirms that the issue is reproducible and detectable under debugging conditions. Attackers could potentially leverage this race condition to crash the kernel, causing a system-wide outage, or extract arbitrary kernel memory contents if the timing allows for successful reading before complete deallocation. Such vulnerabilities undermine the integrity of the virtual frame buffer subsystem and compromise the security boundary between user-space applications and core kernel components.
The resolution involves restructuring the cleanup sequence within the vfb driver to defer resource deallocation until all references are truly gone. Specifically, the registered framebuffer's cleanup logic is moved into an fb_destroy callback function. This ensures that the colormap and screen buffer remain allocated as long as any file descriptor holds a reference to the fb_info structure. The unregister_framebuffer call drops its registration reference but does not trigger immediate destruction; instead, the actual deallocation occurs only after the last put_fb_info() is executed by the kernel subsystem when all user-space references are released. This aligns with standard Linux kernel practices for managing refcounted resources and prevents premature freeing of critical data structures.
This vulnerability maps to CWE-416 Use After Free in common weakness enumeration standards, highlighting the danger of accessing memory after it has been freed due to incorrect lifecycle management. In terms of attack patterns, this scenario reflects aspects of ATT&CK technique T1059 Command and Scripting Interpreter if an attacker uses ioctl calls as part of a broader exploitation chain, although primarily it represents a local resource manipulation flaw rather than direct command execution. Mitigation strategies include applying the provided kernel patch that reorders cleanup operations to respect reference counting semantics. System administrators should ensure their kernels are updated with this fix applied and monitor for any unusual crashes or performance degradation in systems utilizing virtual frame buffers. Regular auditing of driver code against refcounting best practices can prevent similar issues across other subsystems within the Linux kernel architecture.