CVE-2024-53682

What it actually does

Missing ramp_delay value in AXP717 regulator descriptors causes voltage steps to occur without the required 15.625 us/step timing, resulting in unstable power transitions during CPU DVFS.

Why it matters to the business

Devices using the AXP717 PMIC may suffer sudden crashes or instability when the CPU adjusts voltage or frequency, producing unexpected downtime on embedded and Linux-based hardware.

How an attack unfolds

Any workload or script that triggers CPU DVFS causes the regulator driver to change voltage without the documented ramp delay; the AXP717 hardware reacts incorrectly and the kernel panics or the system resets.

How to fix it

Apply the upstream fix in commit 10eb845a87193ef922cd002e0ff4f4759c1e918d or later; rebuild and deploy kernels that define AXP_DESC_RANGES_DELAY and AXP_DESC_DELAY with the correct ramp_delay values for all AXP717 regulators.

How to confirm the fix worked

Verify presence of the AXP_DESC_RANGES_DELAY macro and non-zero ramp_delay fields in drivers/regulator/axp20x.c; confirm the regulator descriptors for DCDC4 and other rails contain the 15.625 us/step value after the update.

Typical attack path

1. Initiate CPU frequency or voltage scaling via DVFS
2. Kernel regulator framework calls axp20x set_voltage without ramp_delay
3. AXP717 performs instantaneous 10 mV or 100 mV steps
4. Hardware or kernel state becomes inconsistent leading to crash

How to detect it

Search kernel logs and crash dumps for oops or panic messages referencing axp20x, regulator, or DVFS around the time of unexpected reboots; correlate with CPU frequency scaling events.

What your security team should do

• Prioritize kernel upgrades containing commit 10eb845a87193ef922cd002e0ff4f4759c1e918d on all AXP717-based systems
• Re-test DVFS workloads after patching to confirm stability
• Monitor kernel logs for regulator-related oops until patches are deployed