Cloudanix VulnDB

CVE-2026-46216

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

May 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A local user may be able to crash certain Linux systems by triggering a bug in Intel graphics driver handling when a media graphics component is disabled.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This is a local denial-of-service flaw in the Linux kernel Intel Xe DRM/HDCP code path. When media GT is disabled through configfs, the kernel may leave the media_gt pointer unset. The vulnerable function, intel_hdcp_gsc_check_status(), dereferences that NULL pointer while evaluating the GSC state, causing a kernel page fault. Depending on kernel configuration and panic settings, this can crash the calling kernel thread, disrupt graphics/HDCP functionality, or panic the system, resulting in loss of availability. The issue requires local access and low privileges; it does not directly provide confidentiality or integrity impact.

Why it matters to the business

An attacker or misconfigured local workload with the ability to trigger the vulnerable graphics/HDCP path could cause system instability or downtime on affected Linux systems using the Intel Xe DRM driver. For desktops, workstations, media systems, or GPU-enabled hosts, this may interrupt display, media, or workload availability. The vulnerability is not known to be exploited in the wild, is not listed in CISA KEV, has very low EPSS, and has no public exploit maturity indicated, so remediation should be prioritized for exposed multi-user systems, systems where untrusted users can access GPU interfaces, and availability-sensitive Linux fleets.

How an attack unfolds

An attacker first obtains local access to an affected Linux system running the vulnerable Intel Xe DRM/HDCP kernel code. They then place the system into a state where media GT is disabled via configfs or otherwise ensure the media_gt object is not allocated. Next, they trigger an HDCP/GSC status check path that calls intel_hdcp_gsc_check_status(). Because the vulnerable kernel code evaluates fields beneath the missing media_gt pointer without first checking whether it is NULL, the kernel attempts to access an invalid memory address. This produces a kernel page fault and may lead to a kernel oops, graphics subsystem failure, or full system panic, depending on runtime settings.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Intel Xe DRM/HDCP NULL pointer dereference, identified by commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1 or the corresponding backport in the applicable stable/vendor kernel stream. No exact package fixed versions were provided in the input, so use distribution security advisories and kernel changelogs to identify the fixed package for each platform. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to GPU/DRM device nodes such as /dev/dri/* to trusted users only, controlling access to configfs, disabling unneeded Intel Xe/HDCP functionality where operationally acceptable, and ensuring kernel panic/reboot policy is configured to recover availability after a crash.

How to confirm the fix worked

Confirm that deployed kernels include the fix by checking vendor advisories, package changelogs, or kernel source for the added NULL check before dereferencing media_gt in intel_hdcp_gsc_check_status(). Validate that systems are no longer running vulnerable kernel builds with uname -a and distribution package tools such as rpm, dpkg, apt, yum, dnf, zypper, or equivalent fleet inventory. On systems where source or debug symbols are available, verify that the xe HDCP code path contains the early return when media_gt is NULL. Operationally, review dmesg or journal logs after upgrade and confirm there are no recurring kernel oops, NULL pointer dereference, page fault, or xe HDCP/GSC errors associated with intel_hdcp_gsc_check_status().

Typical attack path

  1. Gain local access to an affected Linux system with the Intel Xe DRM driver enabled.
  2. Identify whether the system exposes Intel Xe graphics, HDCP, GSC, and configfs interfaces relevant to media GT state.
  3. Disable media GT through configfs or reach an equivalent state where media_gt is not allocated.
  4. Trigger the HDCP/GSC status-checking code path that invokes intel_hdcp_gsc_check_status().
  5. Cause a NULL pointer dereference in kernel space, resulting in a kernel page fault, oops, graphics disruption, or system crash.

How to detect it

To determine whether exploitation or accidental triggering already occurred, review kernel and system logs for crashes involving the Intel Xe DRM driver, HDCP, GSC, and the function intel_hdcp_gsc_check_status(). Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps under kdump or systemd-coredump infrastructure, hypervisor reset events, and endpoint telemetry showing unexpected reboots. Search for NULL pointer dereference, page fault, kernel oops, panic, or general protection fault messages near xe, drm, hdcp, gsc, media_gt, or configfs activity. Correlate any crash timestamps with local user sessions, writes to configfs, changes to GPU device access, container launches with /dev/dri passthrough, or workload activity that invokes protected media or display functionality. There are no network indicators expected because exploitation is local.

  • intel_hdcp_gsc_check_status
  • BUG: kernel NULL pointer dereference
  • kernel NULL pointer dereference
  • Unable to handle kernel NULL pointer dereference
  • Oops:
  • kernel page fault
  • general protection fault
  • Kernel panic - not syncing
  • drm/xe/hdcp
  • xe.*hdcp
  • xe.*gsc
  • media_gt
  • /dev/dri/card
  • /dev/dri/renderD
  • /sys/kernel/config

What your security team should do

  • Inventory Linux systems using Intel Xe DRM graphics drivers, especially multi-user systems, GPU workstations, kiosk/media endpoints, and availability-sensitive hosts.
  • Patch affected systems to a vendor kernel containing the upstream fix or stable backport for commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1.
  • Prioritize remediation where untrusted local users, shared shell access, containers with device passthrough, or broad /dev/dri access are present.
  • Restrict membership in groups that can access DRM/GPU device nodes and avoid exposing /dev/dri/* to untrusted containers or workloads unless required.
  • Limit write access to configfs and other kernel configuration interfaces to trusted administrators only.
  • Monitor kernel logs for NULL pointer dereference, page fault, oops, panic, and Intel xe HDCP/GSC messages until patch coverage is complete.
  • Ensure affected systems have appropriate watchdog, panic-on-oops, and automatic reboot policies aligned with business availability requirements.
  • Because this issue is not in KEV, not associated with ransomware use, and has very low EPSS, handle it as a reliability and local DoS patching priority rather than an internet-scale emergency.

The record

In the Linux kernel, the following vulnerability has been resolved: drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status() When media GT is disabled via configfs, there is no allocation for media_gt, which is kept as NULL. In such scenario, intel_hdcp_gsc_check_status() results in a kernel pagefault error due to &gt->uc.gsc being evaluated as an invalid memory address. Fix that by introducing a NULL check on media_gt and bailing out early if so. While at it, also drop the NULL check for gsc, since it can't be NULL if media_gt is not NULL. v2: - Get address for gsc only after checking that gt is not NULL. (Shuicheng) - Drop the NULL check for gsc. (Shuicheng) v3: - Add "Fixes" and "Cc: <stable...>" tags. (Matt) (cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)

Affected packages

Ecosystem Package Introduced Fixed
openSUSE:Tumbleweed kernel-source 0 7.0.11-1.1

Related vulnerabilities