CVE-2026-31486

What it actually does

This is a local race condition in the Linux kernel PMBus hardware-monitoring regulator code. Voltage get, set, and list operations access PMBus registers and shared regulator state without the same mutex protection used elsewhere, allowing concurrent regulator activity and fault notifications to observe or modify inconsistent state. Successful abuse could cause incorrect regulator voltage operations, kernel instability, hardware power-management disruption, or denial of service; confidentiality impact is not expected.

Why it matters to the business

Systems that use Linux PMBus hardware-monitoring/regulator support may be exposed to local integrity and availability risk. In practical terms, a user or process with local access could potentially destabilize power-management behavior, interfere with hardware regulator settings, or crash affected systems, which can affect uptime for servers, appliances, embedded platforms, and infrastructure devices using PMBus-managed components. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported exploit maturity, so urgency is primarily driven by exposure of multi-user systems and operational criticality rather than active widespread exploitation.

How an attack unfolds

An attacker first needs local execution on a system running an affected Linux kernel with PMBus regulator functionality present and reachable. They then trigger overlapping regulator operations, such as voltage reads, voltage writes, voltage-list queries, and PMBus fault-notification paths, through exposed kernel interfaces or workloads that exercise the PMBus driver. Because the vulnerable code accesses shared PMBus registers and state without consistent locking, the attacker attempts to win a timing race so one operation observes or changes state while another operation is in progress. If successful, this can result in inconsistent voltage-regulator behavior, device faults, kernel warnings, oops/panic conditions, or broader system instability. There is no indication from the provided intelligence that remote unauthenticated exploitation or public weaponized exploit code exists.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the upstream fix for the PMBus regulator locking and notification rework. The corrected implementation protects PMBus regulator voltage operations with the appropriate mutex while moving regulator notifications to worker context to avoid deadlock. No exact fixed package versions were provided, so use distribution or appliance vendor advisories to identify the first fixed kernel for each supported release stream. Where immediate patching is not possible, reduce risk by limiting local interactive access, restricting write access to hwmon/regulator sysfs interfaces, disabling unused PMBus-related drivers or modules where operationally safe, and prioritizing patching for multi-user, embedded, appliance, and hardware-management systems that rely on PMBus devices.

How to confirm the fix worked

Confirm that the running kernel is a vendor-fixed build containing the PMBus regulator patch described as protecting regulator operations with a mutex and reworking pmbus_regulator_notify() to use a worker. Validate both the installed kernel package and the booted kernel, because patched packages do not take effect until reboot. On source-based or custom kernels, verify that PMBus regulator get_voltage, set_voltage, and list_voltage paths are synchronized and that notification processing is deferred outside the update_lock. Check whether PMBus exposure exists by reviewing loaded modules and sysfs entries for pmbus, hwmon, and regulator devices. After remediation, run representative hardware-monitoring and regulator workloads and review kernel logs for absence of PMBus/regulator race symptoms, oopses, panics, or fault storms.

Typical attack path

1. Gain local code execution or an account on a Linux system using the affected PMBus regulator/hwmon code.
2. Confirm PMBus/hwmon/regulator interfaces are present, typically through loaded kernel modules or sysfs regulator/hwmon entries.
3. Run concurrent operations that repeatedly read, list, or attempt to set regulator voltages while also provoking PMBus fault or notification handling.
4. Exploit the missing synchronization window between regulator operations and shared PMBus state access.
5. Cause incorrect regulator state handling, hardware-management disruption, kernel oops/panic, or denial of service.

How to detect it

There are no known public exploit indicators or KEV-listed exploitation signals for this issue. To assess possible prior exploitation, review kernel logs, system journals, and hardware-management telemetry for unexplained PMBus, hwmon, regulator, voltage, power, or fault events that coincide with local user activity. Useful sources include dmesg output, journalctl kernel logs, /var/log/kern.log, /var/log/messages, auditd records for sysfs access, EDR process telemetry, and any platform BMC or hardware-health logs. Look for repeated or concurrent access to /sys/class/hwmon and /sys/class/regulator by non-administrative users or unexpected processes, followed by kernel warnings, oopses, panics, PMBus fault-handler activity, regulator notification errors, voltage anomalies, device resets, or host reboots. Because symptoms overlap with legitimate hardware faults, correlate timestamps with user sessions, cron jobs, stress tools, fuzzers, container workloads, and any process repeatedly reading or writing regulator/hwmon attributes.

• /sys/class/hwmon/
• /sys/class/regulator/
• pmbus
• PMBus
• pmbus_core
• pmbus_regulator_get_voltage
• pmbus_regulator_set_voltage
• pmbus_regulator_list_voltage
• pmbus_regulator_notify
• pmbus_fault_handler
• regulator_notifier_call_chain
• hwmon
• regulator
• Oops:
• kernel panic
• general protection fault
• BUG: unable to handle kernel
• WARNING: CPU:

What your security team should do

• Inventory Linux systems that expose PMBus, hwmon, or regulator functionality, especially servers, embedded devices, appliances, and hardware-management platforms.
• Prioritize kernel updates on systems that are multi-user, host untrusted local workloads, or have operationally critical power-management functions.
• Confirm the patched kernel is actually running after maintenance windows and reboots.
• Temporarily restrict local shell access and permissions to regulator/hwmon sysfs write paths on systems that cannot be patched quickly.
• Monitor kernel logs for PMBus, regulator, hwmon, kernel oops, panic, or unusual power-management events until patching is complete.
• Do not treat this as an internet-facing remote vulnerability unless another exposure path grants local kernel-interface access; focus on local privilege boundaries and availability risk.