Look up another CVE · open CVE-2026-45956 in the interactive tracker
CVE-2026-45956
drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()
Published 2026-05-27 (5 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. 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-45956 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 | fixed | 6.1.170-1 | Update the kernel and reboot. Fixed in 6.1.170-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 6.18.14-1 | Update the kernel and reboot. Fixed in 6.18.14-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.18.14-1 | Update the kernel and reboot. Fixed in 6.18.14-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer.
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/exynos/exynos_drm_drv.h
drivers/gpu/drm/exynos/exynos_drm_vidi.c
- What this is
- DRM DRIVERS FOR EXYNOSMAINTAINERS section matched on drivers/gpu/drm/exynos/ · dri-devel@lists.freedesktop.org · Supported
- Kernel module
- none to look for. The file would have gone into exynosdrm, and Debian does not compile it into that module, so finding exynosdrm in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_DRM_EXYNOS|CONFIG_DRM_EXYNOS_VIDI' /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 4 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, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_DRM_EXYNOS, CONFIG_DRM_EXYNOS_VIDI
- Reads as
- all on means the file is compiled; any one off means it is not.
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-05-27 (5 months 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 6.0% 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.3 | 5.10.253 | 2987642c5213 |
| 4.3 | 5.15.203 | 65d1213baffa |
| 4.3 | 6.1.167 | 875fa28690e9 |
| 4.3 | 6.6.130 | 21ca24ba51a2 |
| 4.3 | 6.18.14 | b5fc86d753dd |
| 4.3 | 6.19.4 | a540f767642f |
| 4.3 | 7.0 | d3968a0d85b2 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4606-1 | 2026-05-29 | bullseye 5.10.257-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 flaw is reached only through the Exynos DRM primary device node via DRM_IOCTL_EXYNOS_VIDI_CONNECTION (local ioctl path through drm_ioctl), not over the network.
- AC:LAttack complexity, low
- Once the VIDI driver is enabled and the caller passes DRM_AUTH checks, every call uses the wrong context pointer deterministically; the attacker fully controls ioctl arguments and timing without external race luck.
- PR:LPrivileges required, low
- Exploitation requires a local process that can open the primary DRM device and satisfy DRM_AUTH (authenticated DRM client or CAP_SYS_ADMIN, which includes user-namespace admin); it does not require init-namespace root, but unauthenticated users cannot reach the ioctl.
- UI:NUser interaction, none
- No victim interaction is required beyond the attacker (or their already-authenticated DRM client) issuing the malicious ioctl.
- S:UScope, unchanged
- Impact is kernel memory corruption and instability within the same kernel security domain; it is not a VM escape, IOMMU bypass, or cross-authority sandbox break.
- C:HConfidentiality impact, high
- Type-confused reads/writes against a drm_device masquerading as vidi_context can dereference attacker-influenced garbage pointers and, on affected versions in the CVE window, companion paths also allowed unsafe EDID handling; per project guidance, UAF/wrong-free and uncontrolled reads warrant High confidentiality impact.
- I:HIntegrity impact, high
- The ioctl writes connection state and EDID pointers into misaligned drm_device fields and may call drm_edid_free() on attacker-influenced addresses, enabling arbitrary kernel memory corruption and potential control-flow hijack, not merely a benign crash.
- A:HAvailability impact, high
- The fix and commit message document NULL dereferences, out-of-bounds access, and use-after-free outcomes that can oops or panic the kernel; any such crash maps to High availability impact.