Look up another CVE · open CVE-2026-90316 in the interactive tracker
CVE-2026-90316
drm/omap: dsi: Do not copy isr table
Published 2026-09-17 (31 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-90316 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
To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.
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/omapdrm/dss/dsi.c
drivers/gpu/drm/omapdrm/dss/dsi.h
- What this is
- DRM DRIVERS FOR TI OMAPMAINTAINERS section matched on drivers/gpu/drm/omapdrm/ · dri-devel@lists.freedesktop.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid, bookworm · linux-6.12?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
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
Signals
- Published
- 2026-09-17 (31 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.16%, higher than 5.3% 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 |
|---|---|---|
| 2.6.39 | 5.15.221 | b3cbd1451c24 |
| 2.6.39 | 6.1.188 | f6733460b6d4 |
| 2.6.39 | 6.6.157 | 542a6a3ec77c |
| 2.6.39 | 6.12.110 | 2c27a84ba8d1 |
| 2.6.39 | 6.18.52 | 9063b30faae8 |
| 2.6.39 | 7.2.6 | 30810bdf273b |
| 2.6.39 | 7.3 | 97c03b32b28a |
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 UAF is reached from local DRM_IOCTL_MODE_ATOMIC on /dev/dri/card*: dsi_bridge_disable()→dsi_disable()→dsi_sync_vc(), or a command-mode pageflip via omap_crtc_flush()→dsi_update_channel()→_dsi_send_nop()→dsi_vc_send_bta_sync(). Those register stack objects that omap_dsi_irq_handler() later fires from isr_tables_copy; no remote protocol carries this.
- AC:LAttack complexity, low
- The attacker repeats those commits/pageflips so dsi_vc_send_bta_sync()/dsi_sync_vc_vp() register a stack completion then dsi_unregister_isr_vc() after wait_for_completion_timeout(), while DSI BTA/PACKET_SENT IRQs run omap_dsi_irq_handler() on another CPU against the copied table; both sides of the copy-vs-unregister race are attacker-driven.
- PR:LPrivileges required, low
- DRM_IOCTL_MODE_ATOMIC is gated by DRM_MASTER in drm_ioctl_permit(), not CAP_SYS_ADMIN. drm_master_open() makes the first opener of an unclaimed omapdrm card the master, and a seat/video-group user on AM57x/OMAP DSI hardware typically holds that; this is ordinary local privilege, not init-namespace root.
- UI:NUser interaction, none
- The attacker opens /dev/dri/card* and submits their own atomic commits or dirty/page-flip ioctls that call dsi_vc_send_bta_sync() or dsi_sync_vc(); no other user must mount media, confirm a prompt, or attach a panel.
- S:UScope, unchanged
- dsi_call_isrs() running dsi_completion_handler()/dsi_packet_sent_handler_vp() corrupts kernel stack in the same kernel that hosts omapdrm; this is local kernel memory corruption, not a VM, IOMMU, or sandbox-boundary escape.
- C:HConfidentiality impact, high
- dsi_call_isrs() invokes dsi_packet_sent_handler_vp/l4 with isr_data->arg still pointing at a returned dsi_packet_sent_handler_data / DECLARE_COMPLETION_ONSTACK frame; after reuse that object is read as a fake dsi pointer through dsi_read_reg()/REG_GET, which is a UAF read of kernel memory.
- I:HIntegrity impact, high
- The same dangling arg is passed to complete() in dsi_completion_handler and to complete(vp_data->completion) in the packet-sent handlers; a reused stack slot that overwrites the completion pointer lets complete() lock and wake a wait-queue at an attacker-influenced address, a kernel write/control-flow hijack.
- A:HAvailability impact, high
- complete() on a freed stack completion, or dsi_read_reg() through a dangling dsi_data in dsi_packet_sent_handler_vp, oopses or panics the kernel even if the UAF is not turned into a full write primitive.