Look up another CVE · open CVE-2026-89823 in the interactive tracker
CVE-2026-89823
drm: fix race between partial drm_dev_register() failure and ioctl
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89823 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
If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().
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/gpu/drm/drm_drv.c
- What this is
- DRM DRIVERS AND MISC GPU PATCHESMAINTAINERS section matched on drivers/gpu/drm/ · Maintained
- Kernel module
- drm
Check it on the machine
grep -w CONFIG_DRM /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.
lsmod | grep -w drmPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixieBnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- B
- built in on some, a module on others, absent on the rest
- Build switch
- CONFIG_DRM
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-16 (33 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/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.18 | 5.10.270 | 26d916221395 |
| 4.18 | 5.15.221 | 24d28d15c0f7 |
| 4.18 | 6.1.188 | 6729990df9e7 |
| 4.18 | 6.6.157 | a0a7e2e177f2 |
| 4.18 | 6.12.110 | 19dbfe4d586a |
| 4.18 | 6.18.51 | 79d09cfe9030 |
| 4.18 | 7.2.5 | 2d1215a72159 |
| 4.18 | 7.3 | eb197f7d60f0 |
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
- The race is entered by opening a newly published DRM minor (/dev/dri/renderD* or card*) and issuing ioctl/mmap into drm_dev_enter(); that is a local char-dev syscall path, not network, adjacent-radio, or USB packet processing.
- AC:LAttack complexity, low
- The attacker controls the userspace side (inotify on the new node, open, concurrent DRM_RENDER_ALLOW ioctl/mmap) and can force later drm_dev_register() steps to fail after the first minor is live (ENOMEM in create_compat_control_link or drm_modeset_register_all). Modern drivers skip drm_global_mutex, so open is not serialized with register.
- PR:LPrivileges required, low
- The commit's example publishes the render minor first; that node has no CAP_SYS_ADMIN check, and the overlapping ioctls are DRM_RENDER_ALLOW. Unprivileged local users on phones, desktops, and GPU VMs routinely open /dev/dri/renderD*.
- UI:NUser interaction, none
- The attacker opens their own DRM fd and issues ioctls; GPU or hotplug display probe runs in kernel driver init and does not require a victim to mount media or open a file.
- S:UScope, unchanged
- The use-after-free is of host-kernel DRM/driver resources that drm_dev_enter() is meant to protect, remaining in the same kernel authority; this is not a VM escape or IOMMU/DMA bypass.
- C:HConfidentiality impact, high
- On drm_dev_register() error, probe rollback frees devm MMIO and driver objects while an in-flight drm_dev_enter() ioctl/mmap still uses them, a use-after-free that enables kernel memory disclosure.
- I:HIntegrity impact, high
- The same use-after-free of driver state during concurrent ioctl/mmap allows heap spraying, arbitrary writes, and control-flow hijack, matching kernel guidance that UAF is Integrity High.
- A:HAvailability impact, high
- Racing ioctl/mmap against probe teardown oopses or panics via stale mappings or freed objects; a use-after-free also crashes when not fully exploited.