CVE-2026-46247

What it actually does

This is a local denial-of-service flaw in the Linux kernel clock framework path used by Qualcomm GFX3D/GPU clock handling. A regression in clock-rate determination leaves the parent request map without the expected parent clock hardware pointer, so when the kernel evaluates or changes the GFX3D clock rate it can crash in the clk/divider/devfreq call chain. The impact is availability loss: a kernel oops, panic, device reboot, or GPU/device instability. The CVSS vector indicates local access, low complexity, low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels on impacted Qualcomm GPU/SoC platforms may become unstable or reboot when GPU frequency scaling is exercised. For phones, embedded devices, appliances, edge systems, or servers using affected hardware, this can cause service interruptions, watchdog resets, data processing disruption, and reduced reliability. The current EPSS is very low and the issue is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, local users, applications, containers with access to relevant GPU/device interfaces, or untrusted workloads on affected hardware could still trigger operational outages.

How an attack unfolds

An attacker first needs local code execution or another local ability to drive GPU/devfreq activity on an affected kernel and Qualcomm graphics clock configuration. The attacker then causes activity that results in the kernel changing or evaluating the GFX3D clock rate, such as GPU workload changes that invoke devfreq and OPP rate-setting paths. During clock-rate determination, the affected kernel follows the Qualcomm GFX3D clock path and reaches the divider/parent-selection logic with an incomplete parent request map. Because the expected parent clock hardware value is not present, the kernel hits the crash condition in the clock framework call chain. Successful exploitation results in a local denial of service, typically seen as a kernel oops, panic, GPU subsystem failure, or system reboot rather than code execution.

How to fix it

Apply a Linux kernel update from the distribution, device vendor, or kernel maintainer that includes the fix for the Qualcomm GFX3D clock parent request map issue, specifically the change that sets the parent clock field in the parent request as well as in the main request. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories, downstream kernel changelogs, or backport notes referencing the Qualcomm GFX3D clock fix. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted applications, limiting access to GPU/render device nodes where operationally feasible, isolating untrusted workloads from affected hardware, and using watchdog/HA controls to recover from crashes. Mitigations should be treated as temporary because the root cause is in kernel clock-rate handling.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backport for the Qualcomm GFX3D clock parent request map fix. Review kernel package changelogs, vendor advisories, source patches, or build metadata for references to the GFX3D clock fix, parent_req, best_parent_hw, clk: qcom: gfx3d, or the commit resolving the crash after the divider determine_rate change. On affected hardware, verify stability under normal GPU/devfreq activity after patching and confirm that kernel logs no longer show crashes in the clk_hw_round_rate, clk_divider_bestdiv, clk_gfx3d_determine_rate, dev_pm_opp_set_rate, or msm_devfreq_target call path. Exposure can be checked by identifying systems running Linux on Qualcomm platforms with msm DRM/GPU support and affected kernel code present.

Typical attack path

1. Obtain local execution on a system running an affected Linux kernel on impacted Qualcomm GFX3D/GPU clock hardware.
2. Identify that the system exposes GPU/devfreq/OPP behavior reachable by the attacker’s process or workload.
3. Generate GPU or graphics activity that causes dynamic frequency scaling or clock-rate recalculation for the GFX3D clock.
4. Trigger the vulnerable clock-rate determination path in the kernel.
5. Cause a kernel crash, panic, watchdog reset, or device reboot, resulting in denial of service.

How to detect it

Look for evidence of kernel crashes or reboots associated with Qualcomm GPU clock-rate changes. Useful sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, persistent pstore/ramoops logs, crash dump records, kdump/vmcore analysis, mobile or embedded device crash logs, and watchdog reset telemetry. Search for stack traces containing clk_hw_round_rate, clk_divider_bestdiv, divider_determine_rate, clk_gfx3d_determine_rate, dev_pm_opp_set_rate, msm_devfreq_target, devfreq_monitor, worker_thread, or Qualcomm msm GPU/devfreq components. Correlate crashes with local user sessions, newly installed or suspicious applications, GPU-heavy workloads, container jobs, render device access, or repeated reboot patterns. There are no known public threat actors, ransomware campaigns, or network indicators associated with this issue from the provided input; detection is therefore primarily host-forensic and reliability-log based.

• clk_hw_round_rate
• clk_divider_bestdiv
• divider_determine_rate
• clk_alpha_pll_postdiv_determine_rate
• clk_gfx3d_determine_rate
• dev_pm_opp_set_rate
• msm_devfreq_target
• devfreq_monitor
• drivers/clk/qcom/clk-rcg2.c
• drivers/gpu/drm/msm/msm_gpu_devfreq.c
• best_parent_hw
• GFX3D
• qcom: gfx3d
• Kernel panic
• kernel BUG
• Oops
• Unable to handle kernel NULL pointer dereference
• watchdog: BUG: soft lockup
• /sys/class/devfreq
• /dev/dri/renderD

What your security team should do

• Inventory Linux systems and embedded devices using Qualcomm GPU/GFX3D hardware or msm DRM GPU drivers.
• Prioritize patching affected devices that run untrusted local code, support multi-user access, expose GPU acceleration to applications or containers, or require high uptime.
• Track distribution and device-vendor kernel advisories because fixed versions are vendor/backport-specific and were not provided in the CVE input.
• Restrict local access and GPU device-node access for untrusted users or workloads until patched.
• Monitor kernel logs for oops, panic, watchdog reset, or reboot events with Qualcomm clock, devfreq, OPP, or msm GPU stack traces.
• For appliances and edge devices, validate that watchdog and high-availability recovery behavior works as expected, but do not rely on restart mechanisms as the sole control.
• Because EPSS is low, exploit maturity is listed as none, and the issue is not in KEV, handle as a reliability and local abuse risk rather than an internet-facing emergency unless affected devices run untrusted local workloads.