Look up another CVE · open CVE-2026-89585 in the interactive tracker
CVE-2026-89585
auxdisplay: charlcd: cancel backlight work on registration failure
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/auxdisplay. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-89585 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/auxdisplay/charlcd.c
- What this is
- AUXILIARY DISPLAY DRIVERSMAINTAINERS section matched on drivers/auxdisplay/ · Odd Fixes
- Kernel module
- none to look for. The file would have gone into charlcd, and Debian does not compile it into that module, so finding charlcd in lsmod would say nothing about this CVE.
Check it on the machine
grep -w CONFIG_CHARLCD /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- Build switch
- CONFIG_CHARLCD
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/auxdisplay
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.12 | 5.15.221 | cd97b3c68fe3 |
| 4.12 | 6.1.188 | 22586432c1ab |
| 4.12 | 6.6.157 | 6eaed64a32e5 |
| 4.12 | 6.12.109 | fe7ba73dde94 |
| 4.12 | 6.18.50 | 84858671842a |
| 4.12 | 7.2.4 | ff2fb3c1e60c |
| 4.12 | 7.3 | e3e3bf40916c |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- charlcd_register() is reached only from local auxdisplay probe (hd44780 platform, lcd2s I2C, panel parport) on character LCDs in embedded, industrial, and appliance systems; there is no network or USB-host packet path into this misc-registration error path.
- AC:LAttack complexity, low
- CONFIG_CHARLCD_BL_FLASH is the default, so charlcd_init() always queues bl_work (L* poke, 4s) before misc_register(); a second charlcd consumer or LCD_MINOR 156 collision makes registration fail deterministically, then the work runs on the freed object with no attacker-uncontrollable race.
- PR:LPrivileges required, low
- On multi-display or mixed hd44780/lcd2s/panel systems the second probe runs automatically at boot without init-namespace root, and an unprivileged local user can spray the heap in the 4s window; embedded/kiosk sysfs bind is also not strictly root-only. Uncertain vs High, so Low.
- UI:NUser interaction, none
- The UAF is armed during driver probe and consumed by the kernel workqueue; no victim needs to open /dev/lcd, mount a filesystem, or take any other interactive action.
- S:UScope, unchanged
- The delayed-work UAF corrupts in-kernel charlcd_priv/work_struct heap state and can escalate only within the host kernel; it does not cross a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- charlcd_bl_off() does container_of() on the freed delayed_work and reads priv fields, including lcd.ops, from reclaimable slab, giving a use-after-free kernel read primitive.
- I:HIntegrity impact, high
- The same callback invokes priv->lcd.ops->backlight on the freed object, so reclaiming the slab with a forged ops table yields a kernel function-pointer call, arbitrary write, and control-flow hijack.
- A:HAvailability impact, high
- Running delayed work after charlcd_free() oopses or panics via mutex_lock on freed bl_tempo_lock or a wild ops pointer, even when the UAF is not fully exploited.