CVE-2026-43123

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel framebuffer console subsystem, specifically in the fbcon code path. If con2fb_acquire_newinfo() calls fbcon_open() and that operation fails, the kernel can leave the info->fbcon_par pointer unset and later dereference it. A local user with sufficient ability to interact with console/framebuffer-related functionality may be able to trigger a NULL pointer dereference, causing a kernel oops, panic, or system crash. The impact is availability loss only; the provided CVSS vector does not indicate confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can crash affected Linux systems, causing service interruption, workload disruption, failed jobs, or forced reboots. The risk is most relevant for systems where local users, containers with device access, kiosk/console workloads, graphical terminals, or framebuffer console functionality are exposed. This issue is not listed in CISA KEV, has no known ransomware association, has very low EPSS, and has no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, systems with untrusted local users should still prioritize remediation as part of normal kernel patching.

How an attack unfolds

An attacker first needs local access to an affected Linux system and a way to exercise framebuffer console behavior, such as console switching, framebuffer binding, or other paths that cause fbcon to acquire new framebuffer console information. The attacker then attempts to trigger a failure in fbcon_open() during con2fb_acquire_newinfo(). In the vulnerable kernel path, that failure is not handled correctly, leaving the framebuffer console private data pointer NULL. Subsequent code dereferences the NULL pointer, leading to a kernel fault. Depending on kernel panic settings and system configuration, this may produce a kernel oops, terminate affected kernel activity, or panic and reboot the host, resulting in denial of service.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the fbcon fix adding proper return-value checking for con2fb_acquire_newinfo(). Because no exact fixed package versions were provided, use the relevant distribution advisory and install the latest stable kernel update for the affected release. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the system continues running the old kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to framebuffer and virtual console devices, avoiding unnecessary framebuffer console use, and enforcing device access controls for /dev/fb* and console-related interfaces. On high-availability systems, use maintenance windows and redundant capacity because kernel remediation generally requires rebooting.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated to a vendor build containing the fbcon patch. Validate with uname -a, package manager kernel version checks, and the applicable distribution security advisory. Review bootloader configuration to ensure the patched kernel is the default and verify after reboot. If kernel source or build metadata is available, confirm the fbcon code checks the return value of con2fb_acquire_newinfo() before using the framebuffer console private data. Also confirm framebuffer console exposure is limited where not required by checking loaded framebuffer/fbcon-related modules, active virtual consoles, and permissions on framebuffer devices such as /dev/fb0.

Typical attack path

1. Obtain local access to an affected Linux host with permissions or device exposure sufficient to interact with console/framebuffer functionality.
2. Identify that framebuffer console support is present and active, such as fbcon, framebuffer devices, or virtual console switching.
3. Trigger a code path that causes con2fb_acquire_newinfo() to call fbcon_open() and encounter an error condition.
4. Rely on the vulnerable error-handling path to leave info->fbcon_par as NULL.
5. Cause the kernel to later dereference the NULL pointer in the fbcon path.
6. Induce a kernel oops, panic, reboot, or system instability, resulting in local denial of service.

How to detect it

To determine whether exploitation may have already occurred, review kernel and system logs for crashes or warnings involving the framebuffer console subsystem. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, persistent systemd journal storage, netconsole output, kdump/vmcore artifacts, and centralized EDR/SIEM kernel-event telemetry. Look for NULL pointer dereference, kernel oops, panic, or general protection fault messages near fbcon, fbcon_open(), con2fb_acquire_newinfo(), do_fb_ioctl(), framebuffer, or virtual console activity. Correlate crashes with local login sessions, sudo activity, container/device passthrough events, access to /dev/fb*, console switching, or unusual repeated attempts to interact with framebuffer devices. There are no known public exploit-specific payload strings, network signatures, or named threat actor procedures for this issue based on the provided intelligence, so detection should focus on kernel crash artifacts and local activity immediately preceding them.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• general protection fault
• fbcon_open
• con2fb_acquire_newinfo
• fbcon
• framebuffer console
• /dev/fb0
• /dev/fb1
• /var/crash
• /var/lib/systemd/coredump
• vmcore
• kdump

What your security team should do

• Patch affected Linux kernels through the normal operating system vendor update channel and reboot systems into the fixed kernel.
• Prioritize shared multi-user Linux systems, systems granting local shell access to untrusted users, kiosk/console systems, graphical workstations, and hosts exposing framebuffer devices to containers or sandboxed workloads.
• Inventory hosts with framebuffer console support or accessible /dev/fb* devices and validate whether fbcon is active.
• Restrict access to framebuffer and console devices to trusted users and remove unnecessary device passthrough into containers or virtualized workloads.
• Monitor kernel logs for NULL pointer dereferences, oopses, or panics involving fbcon, con2fb_acquire_newinfo(), fbcon_open(), or framebuffer console activity.
• Ensure crash dump collection, persistent journaling, and centralized kernel log forwarding are enabled so denial-of-service attempts are not lost after reboot.
• Because EPSS is very low, KEV status is false, and no exploit maturity is reported, handle this as a standard-priority kernel availability patch unless local untrusted users or framebuffer device exposure materially increase risk.