CVE-2026-89585

What it actually does

This is a Linux kernel use-after-free in the auxdisplay character LCD (charlcd) driver when CONFIG_CHARLCD_BL_FLASH is enabled. charlcd_init() queues delayed backlight work (bl_work) before charlcd_register() calls misc_register(); if registration fails, the caller frees the charlcd object while the delayed work still holds its address. When that work later runs, the kernel uses a dangling pointer, which can corrupt kernel memory and lead to arbitrary kernel-context execution (local, low-privilege, high confidentiality/integrity/availability impact).

Why it matters to the business

A successful local exploit can give an already-logged-in user full control of the host, including data theft, persistence, and service disruption. Practical exposure is narrow: it requires the character LCD auxiliary-display driver with backlight flashing enabled, which is uncommon outside embedded, industrial, kiosk, or specialty hardware. The issue is not in CISA KEV, is not associated with ransomware, has no known public exploit (maturity none), and has a very low, flat EPSS (~0.0017 over 30 days). Treat it as a standard local privilege-escalation patch on LCD-equipped Linux systems, not as an internet-facing emergency.

How an attack unfolds

An attacker who already has local, low-privileged access on a vulnerable Linux kernel with CONFIG_CHARLCD_BL_FLASH enabled targets the charlcd path. They cause device registration to fail after delayed backlight work has been scheduled, so the charlcd object is freed while bl_work still references it. When the work executes, the kernel follows the dangling pointer (use-after-free). The attacker then tries to reuse the freed object so the work callback operates on attacker-influenced memory, converting the bug into kernel memory corruption and privilege escalation to root. No named threat actors or campaigns are tied to this CVE, and there is no reported in-the-wild exploitation.

How to fix it

Apply the vendor or distribution Linux kernel update that cancels delayed backlight work on charlcd registration failure. The upstream fix introduces charlcd_deinit() to cancel bl_work and turn the backlight off, and uses it both for registration rollback and normal unregistration. If you build custom kernels, merge the corresponding auxdisplay/charlcd patch and rebuild. Where LCD auxdisplay is unused, disable or do not load the charlcd/auxdisplay driver and leave CONFIG_CHARLCD_BL_FLASH off as a compensating control until patched. No specific distro package versions were provided; follow your kernel vendor’s advisory for the exact upgrade.

How to confirm the fix worked

Confirm the running kernel includes the charlcd_deinit() rollback path (vendor changelog, git commit, or distro CVE mapping). On systems that still compile the driver, inspect kernel config for CONFIG_CHARLCD_BL_FLASH and whether auxdisplay/charlcd is built-in or modular (lsmod / /lib/modules). After patching, failed charlcd registration and normal unregistration must cancel pending backlight delayed work and not leave a use-after-free. If the hardware is not required, verify the driver is not loaded and will not autoload. Reproduce only in a lab by exercising registration-failure and unregistration paths and watching for the absence of delayed-work warnings or oopses—not on production hosts.

Typical attack path

1. Obtain local low-privileged access on a Linux host that builds and uses the auxdisplay charlcd driver with backlight flashing (CONFIG_CHARLCD_BL_FLASH).
2. Trigger or wait for a charlcd registration failure after delayed backlight work has already been queued.
3. Allow the delayed work to run against the already-freed charlcd object, producing a kernel use-after-free.
4. Attempt to convert the use-after-free into kernel memory corruption and local privilege escalation.
5. Operate with elevated (root/kernel) privileges if the memory-corruption attempt succeeds.

How to detect it

There is no public exploit or named actor activity, so treat hunting as opportunistic rather than incident-driven. Review kernel logs (dmesg, journalctl -k, persistent /var/log/kern.log or equivalent), kdump/vmcore, and oops/panic collectors for use-after-free, paging-request, or delayed-work faults whose call traces mention charlcd, auxdisplay, or backlight work around driver init, misc_register failure, or unregistration. Correlate with local privilege-escalation symptoms (unexpected uid 0 processes, new root-equivalent credentials, kernel module load) on hosts that actually have LCD auxdisplay hardware. Absence of such oopses does not prove the bug was never hit; it only means a crashable UAF was not observed. Forward kernel crash telemetry into SIEM and retain vmcores from LCD-equipped fleets for at least one patch cycle.

• charlcd
• auxdisplay
• bl_work
• charlcd_init
• charlcd_register
• charlcd_deinit
• Unable to handle kernel paging request
• Use-after-free
• misc_register

What your security team should do

• Inventory Linux hosts (especially embedded, industrial, kiosk, and appliance images) for the auxdisplay/charlcd driver and CONFIG_CHARLCD_BL_FLASH; prioritize those over general-purpose servers.
• Deploy the kernel update that adds charlcd_deinit() / cancels bl_work on registration failure as part of the normal patch cycle; there is no KEV deadline and EPSS remains very low.
• Where character LCD support is unused, blacklist or omit the driver and disable CONFIG_CHARLCD_BL_FLASH until patched.
• Restrict local unprivileged access and module loading on remaining unpatched systems, since exploitation requires local access.
• After patching, sample dmesg/journal and kdump/oops history for prior charlcd/backlight delayed-work faults, then close the ticket with config and version evidence.