UBUNTU-CVE-2026-97604: Use After Free
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. vfbremove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fbinfo. 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 copytouser Read of size 512 by task poc/125 copytouser (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fbcmaptouser (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) dofbioctl (drivers/video/fbdev/core/fbchrdev.c:114) Allocated by task 1: fballoccmapgfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfbprobe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fbdealloccmap (drivers/video/fbdev/core/fbcmap.c:151) vfbremove (drivers/video/fbdev/vfb.c:489) unregisterframebuffer() drops the registration reference, and fbdev calls fbdestroy after the last putfbinfo(). Move the registered framebuffer's cleanup into an fbdestroy callback so its colormap and screen buffer stay alive until all file references have been released.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the fbdev vfb driver, move framebuffer cleanup from vfb_remove() into an fb_destroy callback so the colormap and screen buffer remain allocated until all open-file references to fb_info are released.