Look up another CVE · open CVE-2026-64084 in the interactive tracker
CVE-2026-64084
hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/hwmon. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-64084 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 | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
adm1266_gpio_get_multiple() iterates the PDIO portion of the caller-supplied mask using for_each_set_bit_from(gpio_nr, mask, ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) { ... } where ADM1266_PDIO_STATUS is the PMBus command code (0xE9, i.e. 233), not the number of PDIO pins. The intended upper bound is ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25. gpiolib hands in a mask sized for gc.ngpio (= 25 bits on this chip), so the iteration walks find_next_bit() up to 242, reading up to 217 extra bits (a handful of unsigned-long words: four on 64-bit, seven on 32-bit) of whatever lives past the end of the mask in the caller's stack. Any incidental set bit in that range then drives a set_bit(gpio_nr, bits) call that writes past the end of the caller-supplied bits array too -- both out-of-bounds. Substitute ADM1266_PDIO_NR for the constant so the scan stops at the last real PDIO bit.
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/adm1266.c
- What this is
- HARDWARE MONITORINGMAINTAINERS section matched on drivers/hwmon/ · linux-hwmon@vger.kernel.org · Maintained
- Kernel module
- none to look for. The file would have gone into adm1266, and Debian does not compile it into that module, so finding adm1266 in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_HWMON|CONFIG_PMBUS|CONFIG_SENSORS_ADM1266' /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.
Show whether Debian builds this, per release
Debian does not build this code. In 4 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_HWMON, CONFIG_PMBUS, CONFIG_SENSORS_ADM1266
- 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-07-19 (3 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 2.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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 |
|---|---|---|
| 5.10 | 5.10.258 | d0593e15fdeb |
| 5.10 | 5.15.209 | 17cee2f59029 |
| 5.10 | 6.1.175 | 299efd14c2ed |
| 5.10 | 6.6.142 | 4d1da9a6be5a |
| 5.10 | 6.12.92 | b96c7f0bc071 |
| 5.10 | 6.18.34 | fa7ca363069a |
| 5.10 | 7.0.11 | 2aef8f08c479 |
| 5.10 | 7.1 | d7834d92251b |
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 bug is only reachable through the GPIO character-device ioctl path (gpiolib → adm1266_gpio_get_multiple), which requires local access to /dev/gpiochip* on a system with an ADM1266 present on I2C; it is not triggered by network packets or physical bus access.
- AC:LAttack complexity, low
- Any caller who can request ADM1266 PDIO lines and issue a multi-line GET_VALUES ioctl reliably enters the flawed loop; no race or victim state beyond attacker-controlled ioctl parameters is required.
- PR:LPrivileges required, low
- Exploitation requires only a local account that can open the GPIO char device and request lines (e.g. root, gpio group membership, or a BMC service account with device access), not full init-namespace CAP_SYS_ADMIN; this is plausible on embedded/BMC deployments where ADM1266 is used.
- UI:NUser interaction, none
- Once the attacker has GPIO char-device access, triggering the bug is a single ioctl with no additional victim interaction.
- S:UScope, unchanged
- Impact is kernel stack memory corruption and potential privilege escalation within the same kernel security domain; it does not cross a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- The flawed loop performs out-of-bounds reads of up to ~217 bits beyond the 25-bit mask into adjacent kernel stack memory, constituting kernel memory disclosure per OOB-read guidance.
- I:HIntegrity impact, high
- Incidental set bits found during the out-of-bounds mask scan drive set_bit() writes past the end of the caller-supplied bits array, causing out-of-bounds kernel stack writes that could be leveraged for control-flow hijacking.
- A:HAvailability impact, high
- Stack corruption from the out-of-bounds writes can cause kernel oops, panic, or hang, satisfying the kernel guidance that memory-corruption bugs warrant High availability impact.