CVE-2025-38041

What it actually does

Race condition in sunxi-ng h616 GPU clock handling prevents safe reparenting during PLL frequency changes, allowing concurrent DVFS operations to trigger panfrost driver oops and GPU hangs.

Why it matters to the business

Systems using Allwinner H616 SoCs experience GPU instability and crashes during graphics workloads or power management transitions, reducing reliability for multimedia, compute, and embedded applications until patched kernels are deployed.

How an attack unfolds

An attacker with local access triggers GPU dynamic voltage and frequency scaling through graphics or compute workloads; the missing clock reparenting logic allows the PLL change to race with active GPU operations, resulting in driver faults and device hangs.

How to fix it

Update to a kernel containing commit 1439673b78185eaaa5fae444b3a9d58c434ee78e or later; rebuild and deploy the fixed kernel image on all H616-based devices.

How to confirm the fix worked

Confirm the presence of commit 1439673b78185eaaa5fae444b3a9d58c434ee78e in the running kernel source or binary; exercise GPU DVFS workloads and verify absence of panfrost oops or GPU hangs.

Typical attack path

1. Obtain local execution on an affected H616-based Linux system
2. Initiate GPU-accelerated workloads that invoke DVFS
3. Trigger PLL frequency change without proper reparenting to GPU1 clock
4. Cause race leading to panfrost oops and GPU hang

How to detect it

Review kernel logs for panfrost oops messages and GPU hang indicators on systems running affected sunxi-ng clock code prior to the fix commit.

What your security team should do

• Prioritize kernel upgrade on all H616 hardware within maintenance windows
• Test GPU workloads under DVFS after patching to validate stability
• Monitor kernel logs for panfrost errors on unpatched systems