CVE-2026-46065

What it actually does

This is a local Linux kernel use-after-free vulnerability in the framebuffer deferred I/O subsystem. When a framebuffer device using deferred I/O is hot-unplugged while a user-space process still has an active memory mapping of the graphics buffer, the kernel can free the associated fb_info structure while mappings still reference deferred I/O state. Subsequent access through the stale mapping can operate on freed or undefined kernel state. Depending on allocator state, kernel configuration, device availability, and exploit reliability, this can lead to kernel memory corruption with potential local privilege escalation, information disclosure, or denial of service through a kernel crash. The upstream fix separates deferred I/O mapping state from the lifetime of struct fb_info and invalidates mappings after device removal so later access fails safely with SIGBUS.

Why it matters to the business

Systems that expose framebuffer devices to local users, containers with device access, graphical sessions, embedded Linux devices, kiosks, appliances, and systems supporting hot-pluggable graphics/display hardware may be at risk. Successful exploitation could allow a user with local access to crash the host or potentially gain elevated privileges, compromising workloads and sensitive data on the affected system. The current EPSS score is low and there is no known KEV listing or public exploit maturity reported, but kernel privilege-escalation bugs can become high priority quickly once reliable exploit techniques are published.

How an attack unfolds

An attacker first needs local code execution or an account on an affected Linux system with permission to open and mmap a framebuffer device that uses deferred I/O. The attacker maps the framebuffer memory from user space, keeps the mapping open, and then triggers or waits for removal of the corresponding framebuffer device, such as through hot-unplug of graphics/display hardware or a driver/device lifecycle event. In vulnerable kernels, the framebuffer info structure can be freed while the user-space mapping still exists. The attacker then accesses the stale mapping, causing the kernel to interact with freed state. A simple attempt may produce a kernel oops or denial of service; a more advanced exploit would attempt to groom kernel heap allocations so the freed memory is replaced with attacker-influenced data, converting the stale access into controlled memory corruption and possible privilege escalation.

How to fix it

Upgrade to a Linux kernel release or vendor-maintained kernel package that includes the upstream fix for framebuffer deferred I/O lifetime handling. Because fixed versions were not provided in the input, use the relevant Linux distribution, appliance, or hardware vendor advisory to identify the exact patched kernel build. Where immediate patching is not possible, reduce exposure by restricting access to framebuffer devices such as /dev/fb*, removing unnecessary local user access, avoiding assignment of framebuffer devices into containers or untrusted workloads, disabling or unloading unneeded framebuffer drivers where operationally safe, and limiting hot-pluggable display/graphics device access on multi-user systems. These mitigations reduce exploitability but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is a vendor build containing the deferred I/O lifetime fix, not only that a patched package is installed on disk. Reboot if required so the patched kernel is active. Review vendor changelogs or kernel commit references for the fbdev deferred I/O fix that introduces separate fb_deferred_io_state lifetime management and invalidates mappings after device removal. Validate exposure by checking whether framebuffer devices exist under /dev/fb* and whether untrusted users or containers can access them. On test systems only, a non-destructive validation can include mapping a framebuffer device and confirming that removal/teardown results in safe SIGBUS behavior rather than a kernel oops or use-after-free report.

Typical attack path

1. Obtain local code execution or an interactive local account on an affected Linux system.
2. Identify an accessible framebuffer device, commonly under /dev/fb*, that uses deferred I/O.
3. Open and mmap the framebuffer device from user space, keeping the mapping active.
4. Trigger, induce, or wait for hot-unplug or driver teardown of the mapped framebuffer device.
5. Access the still-open mapping after the framebuffer info structure has been freed.
6. Cause a kernel crash or attempt heap grooming and controlled reuse of freed memory to escalate privileges or disclose kernel memory.

How to detect it

Look for evidence of attempted or successful exploitation in kernel and system logs rather than application logs. Useful sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, auditd logs for device access, container runtime logs for device passthrough, and crash dump artifacts such as vmcore, kdump, pstore, or apport/ABRT reports. Search for kernel oops, panic, KASAN, KFENCE, or UBSAN messages involving fbdev, deferred I/O, framebuffer mmap, device hot-unplug, or access after free. Correlate these events with local processes opening /dev/fb* and with physical or virtual display device removal events. If auditd is enabled, investigate processes repeatedly opening or mmaping framebuffer devices around the time of a hot-unplug or kernel crash. Because no public exploit maturity or named threat actor activity is reported, there are no stable attacker-specific network indicators; detection should focus on local device access patterns, kernel memory-safety warnings, and crash artifacts.

• /dev/fb0
• /dev/fb1
• /dev/fb*
• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• use-after-free
• fb_deferred_io
• fbdev
• framebuffer
• struct fb_info
• SIGBUS
• kernel BUG
• Oops:
• general protection fault
• unable to handle kernel paging request
• Kernel panic
• mmap
• hot-unplug

What your security team should do

• Inventory Linux systems exposing /dev/fb* devices, especially graphical workstations, embedded devices, kiosks, appliances, and systems with hot-pluggable display hardware.
• Prioritize patching systems where untrusted local users, shared shell access, containers with device passthrough, or physical hot-plug access are present.
• Apply the vendor-patched kernel and reboot into the patched version; verify the active running kernel after maintenance.
• Restrict permissions on framebuffer device nodes and remove framebuffer device access from containers, sandboxes, and untrusted workloads unless strictly required.
• Disable or unload unnecessary framebuffer drivers where this is compatible with business operations.
• Monitor kernel logs for framebuffer-related oops, KASAN use-after-free reports, unexpected SIGBUS events after device removal, and suspicious repeated access to /dev/fb*.
• Treat unexplained kernel crashes involving fbdev, deferred I/O, mmap, or hot-unplug events as potentially security-relevant until patched state and root cause are confirmed.