CVE-2025-22009 - Linux Kernel `regulator: dummy` Race Condition and NULL Pointer Dereference

A new Linux Kernel vulnerability, CVE-2025-22009, has caught the attention of embedded device developers and system integrators. This issue revolves around the regulator: dummy driver, which could result in a rare, but serious, NULL pointer dereference during boot. Understanding what went wrong, why it’s dangerous, and how to test or mitigate it is important for anyone working close to the Linux hardware layer.

This exclusive deep-dive will walk you through the details, provide easy sample code snippets, and reference key upstream patches and technical explanations. Let’s break it down in simple terms.

What is the Problem?

When Linux boots and initializes voltage regulators, drivers like the dummy regulator and specific board regulators (for example, anatop_regulator) often try to register and resolve dependencies with each other.

The Bug:
Sometimes, the anatop_regulator_probe() function tries to resolve its supply voltage via the dummy regulator, but the dummy regulator’s driver hasn’t yet completed its probe process. This means a critical pointer (dummy_regulator_rdev) is still NULL, and when kobject_get() operates on it, Linux crashes with a NULL pointer dereference.

Classic Kernel Race Condition:
- Two threads (for example, kworker/u4:*) may run dummy_regulator_probe() and anatop_regulator_probe() concurrently.

At the crash, the stack looks like

anatop_regulator_probe()
  devm_regulator_register()
    regulator_register()
      regulator_resolve_supply()
        kobject_get()

The main problem is that kobject_get() is handed a NULL pointer, causing the kernel oops.

How can attackers exploit this?

- Typical Impact: Generally, this bug leads to random crashes at boot, not a remote code execution surface. However, a malicious device or crafted device tree could, in *theory*, repeatedly trigger the race and cause system unavailability (DoS).
- In the Wild: It's mostly a stability/reliability bug but could be annoying for secure boot environments that rely on stable initializations.

Proof-of-Concept (PoC) for triggering the bug:
You can only trigger this if you have a Linux board using both the dummy regulator and another regulator (like anatop). You can simulate rapid reproducibility with kernel module insertion/removal in a test lab, but in production, it's a race at boot.

Leak In Log Example

If you add debug lines or additional BUG_ON() statements as testers have done, you may see logs like:

[   1.322319] BUG: unable to handle kernel NULL pointer dereference at 00000000
[   1.322678] IP: kobject_get+x20/x60
...
[   1.323052] Call Trace:
[   1.325932]  regulator_resolve_supply+x39/xc
[   1.326762]  regulator_register+x20f/x480
[   1.327352]  devm_regulator_register+x46/x70
[   1.328012]  anatop_regulator_probe+xdf/x110

The Fix: Force Synchronous Probing

Solution:
The maintainers decided to ensure that the dummy regulator driver is probed synchronously at boot. This guarantees that the dummy_regulator_rdev pointer is valid and ready whenever any other device wants to reference it.

Patch Snippet from Upstream Kernel
(See commit details)

static int __init dummy_regulator_init(void)
{
    struct regulator_desc *desc = &dummy_regulator_desc;
    struct regulator_config config = { };
    int ret;

    // Do this *synchronously* to avoid the race
    dummy_regulator_rdev = regulator_register(desc, &dummy_regulator_dev, &config);
    if (IS_ERR(dummy_regulator_rdev))
        return PTR_ERR(dummy_regulator_rdev);

    return ;
}
subsys_initcall_sync(dummy_regulator_init);

What changed?
Before:

Used subsys_initcall(dummy_regulator_init); (asynchronous, could run in parallel)

After:

References and Further Reading

- Original Kernel Patch Mail
- Linux Kernel Regulator Subsystem Documentation
- LKML Discussion Thread

If it uses subsys_initcall_sync(dummy_regulator_init), you are protected.

2. Dmesg/Kernel Logs:

Devices Affected:

- Boards using Device Tree with dummy regulators and dependent supplies (Fast-moving embedded/ARM SoC boards) are most frequently exposed.

How to Patch

Upgrade your kernel to include the fix. If you build your kernel from source, port or apply the patch directly:

git cherry-pick <commit-sha-for-fix>
make && make modules_install && make install
# Reboot system

Conclusion

CVE-2025-22009 is a fascinating example of a low-level Linux race condition that can lead to unpredictable and frustrating boot crashes for embedded systems. While not a privilege escalation or remote exploit, its impact on reliability makes it a critical fix for anyone maintaining custom Linux builds or working on upstream kernel tooling.

Remember:
Always keep your hardware-near kernel code up to date and watch out for subtle races—sometimes the most dangerous bugs happen only when two modules load at just the wrong time.


Author:
Linux Device Internals Team, 2024

Enjoyed this deep dive? Follow more at kernel.org and LKML!

Timeline

Published on: 04/08/2025 09:15:24 UTC
Last modified on: 04/10/2025 13:10:51 UTC