CVE-2026-74424 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
fbcon: fix NULL pointer dereference for a console without vc_data
fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and
passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the
mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data.
Keep fb_display[i].mode set only while the console has a vc_data. Check
vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's framebuffer console subsystem, specifically affecting the fbcon driver's handling of console state management during modelist changes. The issue stems from a fundamental race condition and state inconsistency between framebuffer display management and virtual console data structures. When fbcon_new_modelist() processes changes to framebuffer modes, it iterates through all consoles that have their mode set in fb_display[i].mode without proper validation of the underlying virtual console data structure. This flaw creates a scenario where the system assumes every console with an active mode also possesses a valid vc_data structure, which is not always true.
The technical implementation flaw occurs because fbcon_set_disp() performs operations in an incorrect sequence that leaves the mode flag set even after the virtual console data has been freed. Specifically, the function sets fb_display[i].mode before validating whether vc_data exists, creating a window where a NULL pointer dereference can occur during subsequent operations. The fbcon_deinit() function exacerbates this issue by freeing the vc_data structure while leaving the mode flag set in the display structure, effectively creating a dangling reference scenario. This sequence violates proper resource management principles and creates an exploitable condition where code attempting to access vc_cons[i].d will encounter a NULL pointer dereference.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable privilege escalation or denial of service attacks within kernel space. Attackers could exploit this condition by manipulating framebuffer console states to force the kernel into accessing freed memory structures, potentially leading to system instability or unauthorized code execution in kernel contexts. The vulnerability affects systems using framebuffer consoles and demonstrates poor state management practices that violate fundamental security principles outlined in common weakness enumeration standards such as CWE-476, which addresses NULL pointer dereference conditions. This issue particularly impacts embedded systems and server environments where framebuffer console functionality is actively utilized.
Mitigation strategies must focus on proper synchronization and validation of console state transitions within the framebuffer subsystem. The recommended fix involves implementing proper checks for vc_data existence before setting mode flags in fbcon_set_disp(), ensuring that mode information is only maintained while valid console data structures exist. Additionally, fbcon_deinit() should clear the mode flag immediately upon freeing vc_data to prevent stale references. These changes align with ATT&CK framework techniques related to privilege escalation and system compromise by addressing memory safety issues at their root cause. The solution also requires implementing defensive programming practices that validate resource states before access operations, preventing the race conditions that typically lead to such vulnerabilities in kernel-level code.