CVE-2025-40323

What it actually does

Use-after-free in the Linux kernel fbcon subsystem: fb_display[] pointers to freed modelist entries are not cleared during framebuffer unregistration, allowing subsequent fb_mode_is_equal and fbcon_mode_deleted calls to dereference dangling pointers.

Why it matters to the business

Local users on systems with dynamic framebuffer devices can trigger kernel crashes or potentially escalate privileges; high-availability servers and embedded devices using console framebuffers face downtime or integrity risks until patched.

How an attack unfolds

An attacker with local access loads a kernel module to register an additional framebuffer device, maps a mode into the global fb_display array, unloads the module to free the modelist without clearing references, then issues ioctls through another framebuffer device to trigger mode deletion and the use-after-free.

How to fix it

Apply the upstream fix commit 4ac18f0e6a6d599ca751c4cd98e522afc8e3d4eb (or equivalent backport) to do_unregister_framebuffer so that any mode present in fb_display[] is set to NULL before the modelist is freed; rebuild and deploy the updated kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting do_unregister_framebuffer for the added NULL check, boot the kernel, repeat the syzkaller reproduction steps, and verify absence of KASAN reports in fb_mode_is_equal.

Typical attack path

1. Register secondary framebuffer device via kernel module
2. Use FBIOPUT_CON2FBMAP or equivalent to store mode reference in fb_display[]
3. Unload module to free modelist memory while leaving wild pointer
4. Issue fb ioctl sequence from primary framebuffer to delete the now-freed mode
5. Trigger fb_mode_is_equal on dangling pointer resulting in UAF

How to detect it

Search kernel logs and crash reports for stack traces containing fb_mode_is_equal, fbcon_mode_deleted, fb_set_var, and KASAN slab-use-after-free messages referencing fb_display or modelist; correlate with recent module load/unload events on framebuffer devices.

• fb_mode_is_equal+0x285/0x2f0
• fbcon_mode_deleted+0x129/0x180
• BUG: KASAN: slab-use-after-free in fb_mode_is_equal

What your security team should do

• Prioritize kernel update containing 4ac18f0e6a6d599ca751c4cd98e522afc8e3d4eb on all systems exposing /dev/fb* devices
• Restrict local access to framebuffer devices via device node permissions until patched
• Monitor kernel logs for fbcon and KASAN reports involving fb_mode_is_equal
• Test updated kernels in staging environments before broad rollout