CVE-2026-64154

What it actually does

This flaw is a Linux kernel reference leak in the Qualcomm MSM/Adreno A6xx DRM GPU initialization path. During a6xx_gpu_init(), the driver obtains a device-tree node reference with of_parse_phandle(), but some early error paths return without releasing that reference. Repeatedly reaching those error paths can leak kernel resources associated with device-node references, potentially degrading kernel stability or contributing to a local denial-of-service condition on systems using affected Adreno A6xx GPU support. The issue is not currently associated with public exploit code, remote code execution, privilege escalation, or known active exploitation.

Why it matters to the business

Systems that rely on affected Linux kernel builds for Qualcomm/Adreno graphics support could experience reliability problems if the vulnerable initialization path is repeatedly triggered, particularly on embedded, mobile, edge, or appliance-like devices where GPU driver stability affects user interface, display, or graphics-dependent workloads. The current exploitation likelihood is low: EPSS is 0.00165, exploit maturity is listed as none, and the issue is not in CISA KEV or associated with ransomware activity. The main operational concern is service instability rather than data theft or broad remote compromise.

How an attack unfolds

A practical attacker would first need access to a system running an affected Linux kernel with the MSM DRM Adreno A6xx driver in use or reachable. The attacker would then need a way to repeatedly force the GPU initialization path into one of the early failure branches that previously skipped the device-node release. This could involve local actions that cause driver probe, bind, unbind, device reset, module reload, or hardware initialization failure cycles, depending on kernel configuration and platform permissions. Each failed initialization attempt could leak a reference. Over time, repeated triggering may consume kernel resources and contribute to degraded stability or denial of service. There is no indication from the supplied intelligence that this is remotely exploitable, weaponized, or used by named threat actors.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the MSM Adreno A6xx driver reference leak. The corrected implementation uses automatic cleanup for the device_node reference so it is released on all exit paths from a6xx_gpu_init(). If vendor kernels are used, apply the kernel update provided by the device, distribution, or appliance vendor rather than relying only on upstream version numbers. No exact fixed package versions were provided in the input, so remediation should be validated against vendor advisories and kernel changelogs referencing the drm/msm/adreno a6xx_gpu_init() reference leak fix. As temporary risk reduction, restrict local administrative access, prevent untrusted users from manipulating driver bind/unbind or module-loading interfaces, and avoid repeated GPU driver reset/probe cycles on affected systems.

How to confirm the fix worked

Confirm that the running kernel or vendor kernel package includes the drm/msm/adreno fix for the a6xx_gpu_init() device_node reference leak. Review the kernel source or vendor patch set for the use of the __free(device_node) cleanup handler, or equivalent guaranteed of_node_put() behavior, for the node returned by of_parse_phandle() in a6xx_gpu_init(). Verify the active kernel version after reboot, not only the installed package version. On exposed systems, check whether the MSM DRM/Adreno driver is present and loaded, for example by reviewing loaded modules, kernel configuration, device-tree hardware, and dmesg output for msm/adreno GPU initialization. Where feasible in a test environment, repeatedly exercise GPU driver probe or failure paths and monitor for stable kernel memory and reference behavior.

Typical attack path

1. Identify a Linux system using the Qualcomm MSM DRM driver with Adreno A6xx GPU support.
2. Obtain sufficient local capability to influence driver initialization, device binding, reset, module loading, or platform hardware state.
3. Trigger conditions that cause a6xx_gpu_init() to fail along an affected early-return path.
4. Repeat the failed initialization path to accumulate leaked device-node references.
5. Cause or wait for resource exhaustion, instability, driver malfunction, or system degradation.

How to detect it

There is no unique on-host artifact that proves exploitation of this reference leak. Detection should focus on evidence that the vulnerable path was repeatedly exercised and that the system subsequently showed kernel resource pressure or GPU-driver instability. Review kernel logs from dmesg, journald, syslog, crash dumps, and persistent kernel logs for repeated MSM DRM or Adreno initialization failures, probe failures, GPU resets, driver bind/unbind events, out-of-memory events, warnings, or kernel taint/crash messages. Audit local administrative activity for repeated writes to sysfs driver bind/unbind controls, module load/unload events, scripted hardware reset activity, or suspicious automation that cycles the GPU driver. On systems with kernel tracing, slab accounting, or debug reference tracking enabled, look for increasing device_node/of_node reference counts or memory growth correlated with repeated a6xx GPU initialization failures. Since no threat actors, malware campaigns, or public exploit strings are provided, detection should be behavioral rather than IOC-only.

• a6xx_gpu_init
• msm_drm
• adreno
• of_parse_phandle
• of_node_put
• /sys/bus/platform/drivers/msm/bind
• /sys/bus/platform/drivers/msm/unbind
• GPU fault
• GPU recovery
• probe failed
• Out of memory
• kernel: msm
• kernel: adreno

What your security team should do

• Prioritize patching affected Linux kernels on systems with Qualcomm MSM/Adreno A6xx GPU hardware or enabled MSM DRM support.
• Use vendor-provided kernel updates for appliances, embedded devices, Android-derived platforms, and distribution kernels, because backported fixes may not align with upstream version numbers.
• Treat this as a stability and local denial-of-service risk rather than a high-likelihood remote intrusion risk unless additional exploit intelligence emerges.
• Limit local users' ability to unload modules, write to driver bind/unbind sysfs controls, or otherwise force repeated GPU driver initialization cycles.
• Monitor kernel logs for repeated MSM DRM, Adreno, GPU probe, bind/unbind, reset, or initialization failures, especially if followed by memory pressure or device instability.
• Track vendor advisories for fixed kernel package versions because no exact affected product or fixed-version list was provided.
• Because the CVE is not KEV-listed, not linked to ransomware, and has low EPSS, handle after internet-facing remote-code-execution and actively exploited kernel issues unless the organization operates many affected embedded or mobile Linux devices.