CVE-2026-80785

What it actually does

Race condition in fbdev sysfs handlers allows concurrent access to fb_info modelist and mode pointers without lock_fb_info(), enabling use-after-free dereference or stale pointer storage when store_modes() frees the list.

Why it matters to the business

Linux systems using framebuffer devices face kernel instability or potential local privilege escalation, increasing risk of downtime or compromise especially on servers or embedded devices with high device exposure.

How an attack unfolds

An attacker with local access triggers simultaneous reads or writes via sysfs mode files while another operation replaces and frees the modelist, causing the reader to dereference freed memory or install a dangling pointer.

How to fix it

Update to a Linux kernel containing the fix that adds lock_fb_info() serialization in show_mode(), show_modes(), and store_mode(), plus the _locked activate variant; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the kernel source contains the locking changes around modelist access, test concurrent sysfs mode operations under load, and verify no use-after-free reports in kernel logs during stress testing.

Typical attack path

1. Obtain local unprivileged access on a Linux system with fbdev enabled
2. Open multiple sysfs handles to /sys/class/graphics/fb*/modes and mode
3. Race store_modes() updates against show_mode/show_modes/store_mode readers
4. Trigger use-after-free or stale pointer write to escalate privileges or crash the kernel

How to detect it

Review kernel logs for use-after-free or slab corruption around fbdev and sysfs; inspect audit logs for unusual concurrent access patterns to graphics device sysfs entries.

What your security team should do

• Prioritize kernel updates on all systems exposing fbdev sysfs interfaces
• Monitor EPSS and exploit maturity for any increase in public PoCs
• Restrict unprivileged access to graphics sysfs nodes where feasible via mount options or LSM policies