CVE-2026-89597

What it actually does

In the Linux kernel fbdev uvesafb driver, uvesafb_init() registers a v86d connector callback before calling platform_driver_register(). If that registration fails, the function returns without unregistering the callback, leaving a dangling kernel connector hook. The later platform-device failure path already performs this cleanup; the driver-registration error path did not. The leftover callback can outlive the failed init and point at torn-down uvesafb code or data, which is a kernel use-after-free. Local, low-privileged access (AV:L, PR:L, UI:N) can then corrupt kernel memory, with high impact to confidentiality, integrity, and availability (CVSS 7.8).

Why it matters to the business

Hosts that still load the uvesafb VESA framebuffer fallback (older hardware, some VMs, embedded or recovery images, systems without DRM/KMS) face a local privilege-escalation and kernel-panic risk: a logged-in user could take over the machine or force a reboot. Practical exposure is limited. Exploit maturity is none, EPSS is low and flat (~0.0017 over 30 days, 0% change), the issue is not in CISA KEV, and it is not tied to ransomware or named threat actors. It was published 37 days ago. Modern fleets that never build or load uvesafb have little operational impact; multi-user, developer, and shared Linux systems that still ship CONFIG_FB_UVESA should still patch on a normal kernel-update cycle.

How an attack unfolds

An attacker who already has an unprivileged local session on a Linux system where uvesafb can be loaded (or is auto-loaded for VESA framebuffer) aims to make uvesafb_init() fail after the v86d connector callback is registered. The broken error path returns while that callback remains installed. Later connector or v86d activity can invoke the leftover hook against freed or invalid kernel state, producing a use-after-free in kernel context. Successful abuse of that UAF could yield kernel memory corruption, a denial of service (oops/panic), or full local privilege escalation. No public exploit, in-the-wild use, or APT/campaign attribution has been reported; the bug was found by static analysis of kernel init cleanup.

How to fix it

Apply the upstream Linux kernel change that unregisters the v86d connector callback when platform_driver_register() fails in uvesafb_init(), consistent with the existing platform-device failure cleanup. Deploy a distribution or vendor kernel that includes this fbdev/uvesafb fix, then reboot onto that kernel. No exact packaged fixed versions were supplied with this record, so track distro kernel advisories and changelogs for the uvesafb init-failure unregister. If VESA framebuffer is not required, do not load uvesafb: blacklist the module, disable CONFIG_FB_UVESA in custom builds, and use native DRM/KMS drivers so the vulnerable init path never runs. There is no complete configuration-only fix while an unpatched uvesafb can still initialize.

How to confirm the fix worked

Confirm the running kernel includes the uvesafb_init cleanup on platform_driver_register failure (vendor advisory, kernel changelog, or source/patch presence). Inventory whether uvesafb is built (CONFIG_FB_UVESA) and whether the module is loaded, available, or blacklisted. After patching, reboot and verify the new kernel is active. On systems that must not use this driver, confirm uvesafb is absent from loaded modules and that a persistent module blacklist or firmware/boot config prevents autoload. There is no safe production test that deliberately forces the failed-init UAF path; validation is patch presence plus reduced attack surface, not exploit reproduction.

Typical attack path

1. Obtain local unprivileged access on a Linux host that can load uvesafb
2. Cause uvesafb module initialization to fail after the v86d connector callback is registered but without the matching unregister
3. Trigger later connector or v86d activity that invokes the leftover callback
4. Induce a kernel use-after-free against uvesafb/connector state
5. Convert the corruption into a host crash or local privilege escalation

How to detect it

There are no public exploits, KEV reports, or named-actor TTPs for this CVE, so hunt for the failure and crash artifacts rather than a known payload. Review kernel logs (dmesg, journald/kern, crash dumps) around uvesafb module load and init for platform-driver registration failures that are not followed by connector-callback cleanup, and for oops/panic stacks in uvesafb, fbdev, connector, or v86d. Check whether unprivileged users triggered uvesafb autoload or v86d helper execution shortly before a kernel fault. Forensic artifacts include loaded-module lists, kernel ring buffer lines naming uvesafb, vmcore/kdump stacks, and unexpected presence of the v86d userspace helper. Lack of these signals does not prove the bug was never hit on an unpatched kernel; it only means no noisy crash or module-load trail was retained.

• uvesafb
• uvesafb_init
• v86d
• /sys/module/uvesafb
• Call trace: uvesafb
• platform_driver_register
• fbdev: uvesafb

What your security team should do

• Patch and reboot Linux kernels that include fbdev uvesafb; treat this as a standard high local-LPE kernel update, not a CISA KEV emergency given EPSS ~0.0017, no KEV listing, no ransomware use, and exploit maturity none.
• Inventory CONFIG_FB_UVESA / uvesafb across images and live hosts; blacklist or remove uvesafb wherever VESA framebuffer is unused.
• Prioritize multi-user, CI, developer, and shared hosts over locked-down appliances that never load framebuffer fallback drivers.
• Restrict unprivileged module loading and keep kernel module signing / lockdown policies in place so untrusted users cannot introduce uvesafb.
• Watch kernel logs for uvesafb/v86d oopses after failed init; absence of KEV or named actors does not remove the need to detect local kernel crashes on remaining unpatched systems.