CVE-2026-46252

What it actually does

This is a Linux kernel race/locking flaw in the regulator framework error path. When regulator_resolve_supply() fails while late-enabling a supply regulator, the kernel can call _regulator_put() without holding the required regulator_list_mutex and can clear a supply pointer without sufficient synchronization. The practical impact is kernel instability: lockdep warnings, possible inconsistent regulator state, and in vulnerable configurations a local denial-of-service condition such as a kernel warning, oops, panic, or hang. The CVSS vector indicates local access with low complexity and low privileges, no user interaction, no confidentiality or integrity impact, and high availability impact.

Why it matters to the business

Systems running affected Linux kernel versions may be vulnerable to local availability disruption. The risk is most relevant for Linux-based appliances, embedded systems, mobile/IoT platforms, or servers with hardware and drivers using the kernel regulator subsystem. An attacker who already has local code execution or low-privileged access may be able to crash or destabilize the system, causing service interruption, device reboot, or operational downtime. There is no current KEV listing, no known ransomware association, no reported exploit maturity, and the EPSS score is very low, so internet-scale exploitation urgency is low; however, kernel fixes should still be applied through normal patch cycles, especially on devices where availability is critical.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system, typically as an unprivileged or low-privileged user, or the ability to run code that can influence kernel paths interacting with regulator-backed devices. The attacker then attempts to trigger regulator supply resolution and force the late-enable error path in regulator_resolve_supply(). If the vulnerable kernel reaches the incorrect cleanup sequence, locking rules around regulator object release and supply pointer updates can be violated. Depending on kernel configuration, hardware, drivers, and debug settings, this can generate lockdep warnings and may lead to kernel instability, oops, panic, or a hang. Exploitation is expected to be environment-specific because it depends on the presence and behavior of regulator framework consumers and drivers; it is not a typical remote network-exploitable vulnerability.

How to fix it

Apply a Linux kernel update that includes the regulator core locking fix for regulator_resolve_supply(). Because no exact fixed version was provided, use the kernel packages supplied by the relevant Linux distribution, hardware vendor, Android/device vendor, or upstream stable kernel branch, and verify that the patch changing the error path to use regulator_put() and adding locking around supply pointer clearing is included. For systems that cannot be immediately updated, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling unnecessary device access interfaces, and applying least-privilege controls around hardware-management, debug, and power-management interfaces. On embedded or appliance platforms, obtain firmware or BSP updates from the vendor and prioritize devices where an unexpected reboot or hang would cause operational impact.

How to confirm the fix worked

Confirm the running kernel has been updated to a build containing the regulator core fix. Validate by checking distribution/vendor advisories, package changelogs, kernel source patches, or commit history for the regulator_resolve_supply() locking correction. After patching, reboot into the updated kernel and verify with uname -a and package-manager metadata that the vulnerable kernel is no longer running. Review dmesg, journal logs, and kernel logs after boot and during regulator/device initialization for absence of regulator_resolve_supply(), _regulator_put(), and lockdep warning call traces. Where feasible, run platform-specific hardware initialization or power-management regression tests to ensure regulator-backed devices initialize cleanly without kernel warnings or panics.

Typical attack path

1. Obtain local access to a system running a vulnerable Linux kernel.
2. Identify whether the system uses regulator framework drivers or hardware paths that can trigger regulator supply resolution.
3. Interact with device, driver, power-management, or kernel-exposed interfaces that cause regulator_resolve_supply() to run.
4. Induce or rely on a failure during late enabling of a supply regulator.
5. Trigger the vulnerable error path where regulator cleanup and supply pointer handling occur with incorrect locking.
6. Cause kernel warning, oops, panic, hang, or other availability-impacting instability.

How to detect it

To determine whether this issue may already have been triggered, review kernel logs rather than application logs. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal entries from the kernel facility, pstore/ramoops crash logs, vmcore/kdump artifacts, and embedded device serial console logs. Look for lockdep warnings or call traces that mention drivers/regulator/core.c, _regulator_put(), regulator_resolve_supply(), or regulator_register_resolve_supply(). Also investigate unexplained reboots, watchdog resets, kernel panics, hangs during device initialization, or repeated power-management/regulator errors around the same time. Because this flaw primarily causes availability impact and does not create a distinctive file, process, registry, or network artifact, attribution to malicious exploitation requires correlation with local user activity, suspicious process execution, device-interface access, container escape attempts, or repeated triggering behavior preceding the kernel warning or crash.

• WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0
• _regulator_put+0x80/0xa0
• regulator_resolve_supply+0x7cc/0xbe0
• regulator_register_resolve_supply+0x28/0xb8
• regulator_list_mutex must be held
• drivers/regulator/core.c
• regulator_resolve_supply
• regulator_register_resolve_supply
• _regulator_put
• lockdep warning

What your security team should do

• Inventory Linux systems and embedded/device fleets that use affected kernel builds, prioritizing appliances, mobile/IoT devices, and platforms with custom hardware drivers.
• Track vendor kernel advisories and update to a fixed kernel or firmware image as part of the next maintenance window; prioritize high-availability systems even though public exploitation likelihood is currently low.
• Restrict local interactive access and untrusted workload execution on vulnerable systems until patched.
• Monitor kernel logs for lockdep warnings, regulator_resolve_supply() traces, _regulator_put() warnings, kernel oopses, panics, or unexplained reboots.
• For embedded products or custom kernels, confirm the regulator core patch is backported into maintained branches and included in released firmware images.
• Add regression testing around power-management, regulator-backed devices, and boot-time device initialization after applying the fix.