CVE-2025-22009

What it actually does

Race condition in the dummy regulator driver leaves dummy_regulator_rdev NULL when anatop_regulator_probe calls regulator_resolve_supply during concurrent kworker probing, resulting in NULL pointer dereference inside kobject_get.

Why it matters to the business

Kernel crashes or boot failures on Linux systems can interrupt services, delay deployments, and require manual intervention or reboots, especially in environments with many dependent regulator drivers.

How an attack unfolds

At boot, separate kernel threads execute dummy_regulator_probe and anatop_regulator_probe concurrently; if the dummy probe has not yet assigned dummy_regulator_rdev, the supply resolution path dereferences NULL. Similar privilege-escalation patterns seen in related kernel CVEs may be adapted by local attackers who can influence boot timing or module loading.

How to fix it

Update the Linux kernel to a version containing commit e26f24ca4fb940b15e092796c5993142a2558bd9 which forces synchronous probing of the dummy regulator; Red Hat RHEL EUS 8.4 users should install firefox 102.3.0-7.el8_4 or later equivalent kernel packages.

How to confirm the fix worked

Boot the patched kernel and confirm via dmesg or JTAG that dummy_regulator_probe completes before dependent probes; verify absence of the reported call stack and that dummy_regulator_rdev is non-NULL at regulator registration time.

Typical attack path

1. Initiate system boot or module load that triggers regulator probing
2. Exploit scheduling so anatop_regulator_probe runs before dummy_regulator_probe completes
3. Trigger regulator_resolve_supply on an unresolved dummy supply
4. Cause kobject_get on NULL pointer leading to panic or controlled crash

How to detect it

Search kernel boot logs, dmesg, and journalctl for the call stack containing anatop_regulator_probe, devm_regulator_register, regulator_resolve_supply, and kobject_get together with messages indicating dummy_regulator_rdev remains NULL.

• NULL pointer dereference at boot time in kobject_get
• anatop_regulator_probe
• dummy_regulator_rdev is still NULL
• regulator_resolve_supply
• kworker/u4

What your security team should do

• Apply the synchronous-probing kernel update immediately on all affected systems
• Prioritize patching for high-density or cloud workloads where boot races are more likely
• Add boot-time regulator probe completion checks to CI pipelines
• Review logs for similar regulator NULL-deref patterns from related kernel CVEs