Look up another CVE · open CVE-2026-72395 in the interactive tracker
CVE-2026-72395
hwmon: (pmbus) Fix passing events to regulator core
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/hwmon. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72395 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Sashiko reports: Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with mutex") introduced a worker to batch regulator events over time using atomic_or(). The delayed worker then passes the combined bitmask unmodified to regulator_notifier_call_chain(). The core regulator subsystem's regulator_handle_critical() function evaluates the event parameter using a strict switch statement. If multiple distinct faults occur before the worker runs (e.g., REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CURRENT), the combined bitmask fails to match any case. This leaves the reason as NULL and completely bypasses the critical hw_protection_trigger(). Fix the problem by passing events bit by bit to the regulator event handler.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/hwmon/pmbus/pmbus_core.c
- What this is
- HARDWARE MONITORINGMAINTAINERS section matched on drivers/hwmon/ · linux-hwmon@vger.kernel.org · Maintained
- Kernel module
- pmbus_core
Check it on the machine
grep -wE 'CONFIG_HWMON|CONFIG_PMBUS' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w pmbus_corePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/arm64, arm64/cloud-arm64, arm64/rt/arm64, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_HWMON, CONFIG_PMBUS
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/hwmon
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.6.143 | 6.6.145 | 2106bf405685 |
| 6.12.92 | 6.12.97 | 48fe43666950 |
| 6.18.21 | 6.18.40 | 489291b6b569 |
| 7.0 | 7.1.5 | b0ff6b6ae9c5 |
| 7.0 | 7.2 | 9ef7dacd4421 |
| 6.19.11 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The flaw is only reachable through the PMBus SMBALERT threaded IRQ handler (pmbus_fault_handler) that reads hardware fault status over I2C; there is no network, adjacent-radio, or direct physical-device API path, but local actors on PMBus-equipped servers, routers, and embedded boards can induce multi-fault conditions.
- AC:LAttack complexity, low
- _pmbus_get_flags() ORs multiple REGULATOR_EVENT_* bits from a single STATUS read, and pmbus_regulator_notify() further batches concurrent IRQs via atomic_or() before the worker runs, so combined masks like UNDER_VOLTAGE|OVER_CURRENT are produced deterministically without races or layout dependencies the attacker cannot influence.
- PR:LPrivileges required, low
- Triggering the IRQ requires causing real PMBus regulator fault bits (e.g., over-current plus under-voltage during supply stress), which an unprivileged local user can induce through heavy workload and power instability on affected platforms; CAP_NET_ADMIN/user-namespace tricks are not needed and no init-namespace root capability is required.
- UI:NUser interaction, none
- Once fault conditions are present the SMBALERT IRQ and workqueue fire automatically through pmbus_fault_handler and pmbus_regulator_notify_worker; no separate victim action such as mounting media, plugging hardware, or approving a prompt is required.
- S:UScope, unchanged
- The impact is bypassing kernel hw_protection_trigger() orderly shutdown/reboot for system-critical PMBus regulators on the same host; it does not cross VM, IOMMU, or sandbox security boundaries and is not a guest-to-host escape.
- C:NConfidentiality impact, none
- This is a notifier bit-mask logic error that leaves regulator_handle_critical() with a NULL reason; there is no kernel memory corruption, use-after-free, or out-of-bounds access that could disclose pointers or arbitrary memory.
- I:HIntegrity impact, high
- When multiple distinct fault events are combined, hw_protection_trigger() is completely skipped for system-critical regulators, defeating the kernel's mandatory emergency shutdown policy and allowing continued operation under simultaneous critical under-voltage/over-current/fail conditions that can corrupt power hardware.
- A:HAvailability impact, high
- Bypassing hw_protection_trigger() during simultaneous critical PMBus regulator faults prevents the intended emergency orderly_poweroff/reboot, leaving telecom, data-center, and embedded systems running under dangerous rail conditions that can cause hardware failure, forced resets, and sustained denial of service.