CVE-2026-45956

What it actually does

This vulnerability is a Linux kernel driver flaw in the Exynos DRM VIDI component. The affected ioctl path, vidi_connection_ioctl(), obtains driver context from the wrong device object: it reads driver_data from the Exynos DRM master device instead of the VIDI component device. As a result, kernel code may treat unrelated or invalid memory as a struct vidi_context. Depending on memory layout and runtime state, this can cause null pointer dereferences, invalid pointer dereferences, out-of-bounds access, use-after-free conditions, kernel crashes, or potentially local privilege escalation through kernel memory corruption. The CVSS vector indicates local access is required, low attack complexity, low privileges, no user interaction, and potential high impact to confidentiality, integrity, and availability.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privileged process on an affected Linux system to crash the host or potentially gain elevated kernel-level privileges. The practical risk is highest on systems using Exynos DRM/VIDI functionality, such as embedded, mobile, ARM-based, or specialized Linux deployments. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local kernel privilege-escalation bugs remain important because they can turn an initial foothold into full system compromise.

How an attack unfolds

An attacker first needs local code execution as a low-privileged user on a system running an affected Linux kernel with the Exynos DRM VIDI driver path reachable. The attacker opens the relevant DRM device node and invokes the vulnerable VIDI connection ioctl. Because the kernel looks up the VIDI context through the wrong device's driver_data, the ioctl handler may operate on an invalid, unrelated, freed, or attacker-influenced memory region. A simple exploit may only trigger a kernel oops or denial of service, while a more advanced exploit would attempt to shape kernel memory so the invalid context access produces controlled memory corruption. If reliable control is achieved, the attacker may be able to read or modify kernel memory and elevate privileges to root. No public exploit maturity is indicated in the provided data, and the vulnerability is not currently identified as KEV-listed exploitation.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the Exynos DRM VIDI context lookup issue. The fix stores and clears the VIDI component device pointer in exynos_drm_private->vidi_dev during bind and unbind, and uses that pointer in vidi_connection_ioctl() to obtain the correct struct vidi_context. No exact fixed package versions were provided, so organizations should consult their Linux distribution, device vendor, or kernel maintainer advisories for the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling or removing the affected Exynos DRM VIDI driver if it is not required, restricting local shell/code-execution access, limiting access to DRM device nodes through permissions and group membership, and applying kernel hardening features such as lockdown, module signing, SELinux/AppArmor policy, and least-privilege service isolation.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the vendor or upstream patch for the Exynos DRM VIDI ioctl context lookup fix. Check distribution changelogs, kernel build metadata, or source patches for changes that introduce exynos_drm_private->vidi_dev handling and use priv->vidi_dev in vidi_connection_ioctl(). On systems where the driver is not required, validate that the Exynos DRM VIDI component is not built, not loaded, or not reachable. Review /proc/modules, kernel config, device tree/platform configuration, and DRM device node permissions. After patching or mitigation, reboot into the corrected kernel and verify with uname/package manager output that the active kernel is the intended fixed build, not merely installed alongside an older vulnerable kernel.

Typical attack path

1. Gain local access to an affected Linux system as a low-privileged user or execute code through another foothold.
2. Confirm the system exposes the Exynos DRM/VIDI driver path and accessible DRM device nodes.
3. Open the relevant DRM device interface from user space.
4. Issue crafted ioctl calls that reach vidi_connection_ioctl().
5. Trigger incorrect context lookup through the Exynos DRM master device instead of the VIDI component device.
6. Cause a kernel crash, invalid memory access, out-of-bounds access, use-after-free condition, or other memory corruption.
7. If exploit development is successful, manipulate the memory corruption to elevate privileges or bypass kernel security controls.

How to detect it

Detection should focus on evidence of local probing or exploitation attempts against the Exynos DRM VIDI ioctl path and on post-exploitation behavior consistent with privilege escalation. Review kernel logs from journalctl, dmesg, /var/log/kern.log, /var/log/messages, and crash dump infrastructure for DRM, Exynos, VIDI, kernel oops, invalid pointer dereference, use-after-free, slab corruption, general protection fault, or panic messages. Correlate these events with local process execution, auditd logs, sudo/authentication logs, container runtime logs, and access to /dev/dri device nodes. If auditd or eBPF telemetry is available, look for untrusted processes opening /dev/dri/card*, /dev/dri/renderD*, or issuing unusual ioctl activity shortly before a kernel fault. Since no public exploit indicators or malware artifacts are provided, absence of known IOCs does not rule out exploitation. For suspected incidents, collect kernel crash dumps, process accounting data, audit logs, loaded module lists, command histories, recent file modifications, new setuid files, and evidence of root-level persistence created after the crash or anomalous ioctl activity.

• vidi_connection_ioctl
• drm/exynos
• exynos-drm
• exynos_drm
• vidi
• VIDI
• Oops:
• kernel BUG
• general protection fault
• BUG: unable to handle kernel NULL pointer dereference
• BUG: KASAN: use-after-free
• BUG: KASAN: slab-out-of-bounds
• kernel panic
• /dev/dri/card0
• /dev/dri/renderD128
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching affected Exynos/ARM Linux systems, embedded devices, and appliances where untrusted users or workloads can execute local code.
• Inventory systems running Linux kernels with Exynos DRM/VIDI support and determine whether the affected driver path is enabled or reachable.
• If patching is delayed, disable the Exynos DRM VIDI component or remove access to associated DRM device nodes where operationally safe.
• Restrict membership in groups that can access /dev/dri/* devices and review whether containers or sandboxed workloads are unnecessarily granted DRM device access.
• Monitor kernel logs for oops, panic, use-after-free, invalid pointer dereference, or DRM/Exynos-related crashes that may indicate probing or attempted exploitation.
• Treat suspicious local exploitation attempts as potential privilege-escalation activity and investigate adjacent signs of compromise, including new root-owned files, unusual setuid binaries, kernel module changes, and persistence mechanisms.
• Because the issue is not KEV-listed, has no indicated public exploit maturity, and has low EPSS, schedule remediation based on exposure and asset criticality, but do not ignore systems that allow local multi-user access or run untrusted code.