CVE-2025-40323 in Linux
Summary
by MITRE • 12/08/2025
In the Linux kernel, the following vulnerability has been resolved:
fbcon: Set fb_display[i]->mode to NULL when the mode is released
Recently, we discovered the following issue through syzkaller:
BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: <TASK> dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads
to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);
3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[];
5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0.
Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/23/2026
The vulnerability described in CVE-2025-40323 represents a use-after-free condition within the Linux kernel's framebuffer console subsystem, specifically affecting the fbcon driver. This issue arises from improper memory management during framebuffer device unregistration, creating a dangerous scenario where freed memory continues to be referenced. The vulnerability manifests through a kernel address sanitizer (KASAN) report indicating a slab-use-after-free error in the fb_mode_is_equal function, which is part of the framebuffer mode comparison logic. The flaw occurs when the framebuffer subsystem attempts to validate mode equality after a framebuffer device has been unregistered, leading to access of memory that has already been freed and returned to the kernel's memory allocator.
The technical root cause stems from the incomplete cleanup process during framebuffer unregistration. When a framebuffer device is unregistered, the kernel properly frees the memory allocated for the modelist associated with that device, but fails to nullify the corresponding entries in the global fb_display[] array. This array maintains references to framebuffer modes across different console devices, and when the cleanup process neglects to clear these pointers, they remain as dangling references pointing to freed memory locations. The specific function do_unregister_framebuffer() is responsible for this cleanup operation, and the missing check prevents proper nullification of mode pointers that should be cleared when their associated memory is freed. This creates a situation where subsequent operations attempting to access these freed mode structures result in undefined behavior and potential system instability.
The operational impact of this vulnerability extends beyond simple system crashes, presenting significant security implications within kernel space. Attackers could potentially exploit this use-after-free condition to execute arbitrary code with kernel privileges, leveraging the freed memory for data corruption or information disclosure. The vulnerability is particularly concerning in environments where kernel modules are frequently loaded and unloaded, as the conditions for triggering the flaw can be reproduced through standard device management operations. The described reproduction steps demonstrate how normal system operations involving console switching and module management can lead to exploitation opportunities. The attack surface is broadened by the fact that this affects the core framebuffer console functionality, which is fundamental to system display management and is typically active in all kernel configurations that support graphical interfaces or console operations.
Mitigation strategies for this vulnerability require immediate kernel updates addressing the specific memory management issue in do_unregister_framebuffer(). The fix involves adding a targeted check to ensure that when framebuffer modes are freed, any corresponding entries in the fb_display[] array are properly nullified to prevent subsequent access to freed memory. This approach aligns with established security practices for preventing use-after-free vulnerabilities and follows the principle of defensive programming by ensuring proper nullification of pointers after memory deallocation. Additionally, system administrators should implement monitoring for abnormal kernel memory behavior and consider restricting the loading of untrusted kernel modules. The vulnerability's classification under CWE-416 indicates it is a classic use-after-free scenario, while its exploitation potential aligns with ATT&CK technique T1068 for local privilege escalation. Organizations should prioritize patching this vulnerability as it represents a critical kernel security flaw that could enable unauthorized system compromise through kernel-level attacks.