CVE-2026-45958

What it actually does

This is a local Linux kernel vulnerability in the Exynos DRM VIDI driver. The vulnerable ioctl path directly dereferences a user-space pointer for EDID data instead of first copying it into kernel memory with copy_from_user(). A local user who can reach the affected DRM device interface may cause the kernel to read from an attacker-controlled pointer, which can lead to disclosure of kernel memory and potentially a kernel fault or denial of service. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, high confidentiality impact, and high availability impact.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privilege process to expose sensitive kernel memory or crash affected Linux systems. The risk is highest on systems using affected Exynos DRM components or exposing DRM device nodes to untrusted users, such as shared workstations, embedded Linux devices, kiosks, multi-user systems, and container/desktop environments where local device access is available. This issue is not currently listed in CISA KEV, is not reported as ransomware-used, and has low EPSS, so broad exploitation is not indicated; however, kernel flaws remain operationally important because compromise of a local account can be escalated into deeper host compromise or service disruption.

How an attack unfolds

An attacker first obtains local code execution as a low-privilege user on a system with the affected Linux kernel driver present and reachable. The attacker identifies accessible DRM device nodes, such as /dev/dri/card* or related render/control nodes, and interacts with the Exynos VIDI ioctl interface. By supplying a crafted EDID pointer, the attacker triggers the vulnerable vidi_connection_ioctl() path where the kernel directly dereferences user-controlled memory. Depending on memory layout, kernel configuration, and runtime protections, this may leak kernel memory contents to user space or trigger a kernel fault that crashes the driver path or the system. Exploitation does not require network access or user interaction, but it does require local privileges and access to the affected device interface.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the fix for the Exynos DRM VIDI user-pointer handling issue. The corrected code copies EDID data from user space into kernel memory using copy_from_user() before use. No exact fixed kernel versions were provided in the input, so track the relevant distribution, device vendor, or upstream stable kernel advisory for package-specific fixed releases. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the affected Exynos DRM/VIDI driver if it is not required, restricting access to DRM device nodes to trusted users only, removing untrusted local shell access, and limiting container or sandbox access to host /dev/dri devices. Treat mitigations as temporary; kernel update remains the durable fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for the Exynos DRM VIDI ioctl user-pointer handling bug. Validate both the installed kernel package and the booted kernel with standard commands such as uname -a and distribution package tooling. Review vendor changelogs or source patches for the change from direct user-pointer dereference to copy_from_user() in vidi_connection_ioctl(). Check whether the affected driver is present or loaded using lsmod, modinfo, kernel configuration, and /sys/module paths. Confirm that unnecessary DRM device nodes are not exposed to untrusted users and that /dev/dri permissions are restricted appropriately. If a mitigation was applied by disabling the driver, verify it remains unloaded after reboot.

Typical attack path

1. Gain local execution as a low-privilege user on an affected Linux system.
2. Check whether Exynos DRM/VIDI components are present and whether DRM device nodes are accessible.
3. Open the relevant /dev/dri device node from user space.
4. Issue a crafted ioctl request to the VIDI connection handler with a controlled EDID pointer.
5. Trigger direct kernel dereference of the supplied user pointer.
6. Use the resulting behavior to disclose kernel memory or cause a kernel fault/denial of service.

How to detect it

Detecting prior exploitation is difficult because the vulnerability is triggered through a local kernel ioctl and may not produce application-level logs. Focus on host telemetry and kernel artifacts. Review kernel logs, system journal, crash dumps, and panic/oops records for references to vidi_connection_ioctl, Exynos DRM, VIDI, EDID handling, DRM ioctl failures, page faults, general protection faults, or kernel oops events. Investigate unexpected reboots, kernel panics, or crashes on systems with Exynos DRM components. If auditd, eBPF, EDR, or syscall tracing is available, look for unusual local processes repeatedly opening /dev/dri/card*, /dev/dri/renderD*, or /dev/dri/controlD* and issuing ioctl calls, especially from non-graphical services, temporary directories, user-writable paths, or recently created binaries. Review shell history, process execution logs, and file creation events for locally compiled proof-of-concept tools interacting with DRM devices. On systems using crash collection, inspect vmcore or kdump artifacts for stack traces involving the Exynos DRM VIDI path. Absence of these artifacts does not prove non-exploitation, because a successful information disclosure may leave minimal evidence.

• vidi_connection_ioctl
• drm/exynos
• exynos-drm
• VIDI
• EDID
• /dev/dri/card
• /dev/dri/renderD
• /dev/dri/controlD
• general protection fault
• kernel NULL pointer dereference
• BUG: unable to handle page fault
• Unable to handle kernel paging request
• Kernel panic
• Oops
• ioctl

What your security team should do

• Prioritize patching affected Linux kernels on systems with Exynos DRM/VIDI support or exposed /dev/dri device nodes.
• Inventory systems where the Exynos DRM driver is present, built into the kernel, or loaded as a module.
• Restrict /dev/dri access to trusted users and avoid passing host DRM devices into untrusted containers or workloads.
• Disable or blacklist the affected Exynos VIDI driver on systems that do not require it.
• Monitor kernel logs for crashes, oops messages, or warnings involving vidi_connection_ioctl, exynos DRM, or DRM ioctl handling.
• Review local privilege boundaries on shared Linux systems because this vulnerability requires local access but can be triggered by low-privilege users.
• Track distribution and hardware-vendor advisories for exact fixed kernel package versions, since no fixed versions were provided.
• Because the issue is not currently KEV-listed and has low EPSS, align urgency with asset exposure, multi-user access, and device criticality rather than internet exposure alone.