CVE-2026-64245

What it actually does

This is a Linux kernel use-after-free flaw in the framebuffer device mode database code, specifically in fb_find_mode(). When no explicit mode option is provided, the function obtains a framebuffer mode string into a temporary buffer, assigns another pointer to reference that same buffer, frees the buffer too early, and then continues using the aliased pointer during mode-name matching. Depending on allocator state and call context, this can cause kernel memory corruption, a kernel crash, or potentially more serious behavior if an attacker can control timing and heap reuse. Practical exploitability appears limited because triggering the vulnerable path generally requires influence over framebuffer mode configuration, boot/module parameters, or driver initialization paths. No public exploit maturity, KEV listing, or ransomware usage is currently indicated, and the EPSS score is low at 0.0016.

Why it matters to the business

The most likely operational consequence is instability or denial of service on Linux systems using affected framebuffer code paths, especially during graphics/framebuffer initialization or reconfiguration. In high-availability systems, embedded devices, kiosks, appliances, or systems relying on framebuffer console output, a kernel crash could cause service interruption or require manual recovery. Because this is kernel memory safety code, organizations should still treat it as a kernel patching issue even though current exploitation signals are low, it is not listed in CISA KEV, and no ransomware use is reported.

How an attack unfolds

An attacker would first need a way to cause the vulnerable framebuffer mode-selection code path to execute with a NULL mode_option so that fb_find_mode() retrieves the mode option into an internal temporary buffer. The attacker would then need to influence framebuffer mode configuration, such as through boot-time video parameters, driver/module initialization behavior, or another privileged path that reaches fb_find_mode(). The vulnerable function frees the temporary mode-option buffer while a local pointer still references it, then continues comparing that stale pointer against known mode database entries. If the freed memory is reused before the comparison, the kernel may read corrupted or attacker-influenced data, leading most plausibly to a kernel fault. A more advanced attacker would need to pair the trigger with kernel heap grooming and a controllable reuse primitive to attempt privilege escalation or code execution, but no such exploit path is currently known from the provided intelligence.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fbdev/modedb fix for the fb_find_mode() use-after-free. No exact fixed package versions were provided, so remediation should be tracked through vendor advisories, distribution kernel errata, or upstream stable kernel release notes referencing the framebuffer modedb lifetime fix. Where immediate patching is not possible, reduce exposure by limiting untrusted access to mechanisms that can alter kernel boot parameters, framebuffer/video module parameters, driver loading, or local privileged configuration paths. On systems that do not require framebuffer support, consider disabling unused framebuffer drivers or fbdev functionality according to vendor-supported hardening guidance. Reboot into the updated kernel after installation; installing a kernel package without rebooting usually does not remove exposure from the running kernel.

How to confirm the fix worked

Confirm that the running kernel, not just the installed package, has been updated to a vendor release containing the fbdev modedb fix. Validate with commands such as uname -r, package manager kernel version checks, and vendor advisory mapping for the active kernel build. If building from source, verify that fb_find_mode() no longer frees the mode_option buffer before all uses of the aliased name pointer and that cleanup is deferred until function exit. Review bootloader and kernel command-line settings for video= or framebuffer-related options that could exercise the code path. In test environments, kernel memory sanitizers such as KASAN can be used to confirm that framebuffer mode initialization no longer reports a use-after-free in fb_find_mode(), name_matches(), or fbdev modedb code.

Typical attack path

1. Gain the ability to influence Linux framebuffer mode configuration, kernel boot parameters, module parameters, or a driver initialization path that invokes fb_find_mode().
2. Trigger fb_find_mode() with no direct mode_option value, causing it to populate an internal temporary mode-option buffer.
3. Cause the temporary buffer to be freed while another pointer in the function still references the same memory.
4. Attempt to influence or race reuse of the freed kernel memory before the stale pointer is used during mode-name matching.
5. Cause a kernel fault for denial of service, or in a more advanced scenario, attempt to shape memory reuse for broader kernel memory corruption impact.

How to detect it

Look for evidence of kernel instability or memory-safety faults around framebuffer initialization or mode selection. Primary log sources include systemd journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, crash dumps, kdump/vmcore analysis, kernel panic records, and endpoint telemetry that captures kernel oops events. Search for KASAN or kernel oops reports mentioning fb_find_mode(), name_matches(), fbdev, modedb, framebuffer drivers, or slab-use-after-free/use-after-free near display, video, or framebuffer initialization. Also review bootloader configuration and kernel command-line history for recent or unauthorized changes involving video=, fbdev, framebuffer, or driver-specific mode parameters. Because no specific public exploit or actor tradecraft is indicated, detection should focus on anomalous kernel crashes correlated with framebuffer mode handling rather than network indicators.

• fb_find_mode
• name_matches
• fbdev: modedb
• modedb
• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• use-after-free in fb_find_mode
• kernel BUG at drivers/video/fbdev
• drivers/video/fbdev/core/modedb.c
• Oops:
• Kernel panic
• video=

What your security team should do

• Prioritize normal-cycle kernel patching across Linux systems, with faster handling for internet-exposed appliances, embedded devices, kiosks, graphical consoles, and systems where framebuffer drivers are enabled and availability is critical.
• Verify that patched kernels are actually running after reboot, since stale running kernels remain vulnerable even after package installation.
• Restrict administrative paths that can modify bootloader entries, kernel command-line parameters, module parameters, or load framebuffer-related drivers.
• Monitor vendor advisories for exact fixed kernel versions and distribution-specific backports, as no fixed versions were provided in the input.
• Because current exploitation indicators are low, not KEV-listed, and no ransomware use is reported, treat this as a kernel hardening and reliability update unless local threat modeling identifies untrusted users with access to framebuffer or boot/module configuration paths.
• Add detection coverage for kernel oops, KASAN, or panic messages referencing fb_find_mode, fbdev, modedb, name_matches, or use-after-free conditions.
• For fleets with custom kernels, ensure the upstream lifetime-management patch is included and regression-tested before deployment.