CVE-2026-64084

What it actually does

This is a Linux kernel out-of-bounds read and potential out-of-bounds write in the ADM1266 PMBus hardware monitoring GPIO driver. The vulnerable adm1266_gpio_get_multiple() path uses a PMBus command value as a loop bound instead of the real number of PDIO pins, causing the kernel to scan beyond the caller-provided GPIO mask. If incidental bits are set in adjacent stack memory, the function can also write beyond the caller-provided output bitmap. Because this occurs in kernel context, successful exploitation could corrupt kernel memory and may lead to local privilege escalation, kernel information disclosure, or denial of service through a crash.

Why it matters to the business

Systems using Linux kernels with the vulnerable ADM1266 hardware monitoring driver may be exposed to local privilege escalation or kernel crashes if an attacker already has local code execution or a low-privileged account. The risk is highest for embedded, appliance, server-management, industrial, or hardware-control environments that actually use Analog Devices ADM1266 PMBus devices or load the adm1266 driver. The vulnerability is not known to be exploited in the wild, is not in the CISA KEV catalog, has very low EPSS, and has no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, affected production systems should still be patched during normal kernel maintenance because kernel memory corruption flaws can have severe consequences when reachable.

How an attack unfolds

An attacker must first obtain local access to a vulnerable Linux system where the ADM1266 PMBus GPIO/hardware-monitoring driver is present and bound to hardware or otherwise reachable through kernel interfaces. The attacker then triggers GPIO multiple-read behavior that reaches adm1266_gpio_get_multiple(). Due to the incorrect loop bound, the kernel scans well past the valid 25-bit GPIO mask into adjacent stack memory. If the out-of-bounds area contains set bits, the same path can set corresponding bits beyond the valid destination bitmap, causing kernel stack or adjacent memory corruption. Depending on memory layout, hardening configuration, and trigger reliability, this may result in a kernel panic, information exposure, or potentially controlled corruption that could be developed into local privilege escalation. No active exploitation or named threat actor activity is currently reported for this issue.

How to fix it

Update to a Linux kernel build that includes the ADM1266 driver fix changing the PDIO scan bound from ADM1266_PDIO_STATUS to ADM1266_PDIO_NR. If vendor fixed package versions are not yet listed, obtain the latest kernel security update from the operating system, appliance, or embedded platform vendor and verify that it includes the upstream hwmon/pmbus/adm1266 patch. Where immediate patching is not possible, reduce exposure by preventing untrusted local users from executing code on affected systems, disabling or unloading the adm1266 driver if the hardware is not required, removing unused ADM1266 device-tree or platform configuration where applicable, and enforcing kernel hardening features such as KASLR, stack protector, hardened usercopy, lockdown, and LSM policy. Do not disable the driver on systems that require ADM1266-based power sequencing or monitoring without validating operational impact.

How to confirm the fix worked

Confirm whether the system is exposed by checking whether the kernel includes the ADM1266 driver and whether it is loaded or bound to an I2C/PMBus device. Review kernel package changelogs or source to verify that adm1266_gpio_get_multiple() uses ADM1266_PDIO_NR as the PDIO iteration bound rather than ADM1266_PDIO_STATUS. On source-based systems, inspect drivers/hwmon/pmbus/adm1266.c for the corrected loop bound. On packaged systems, verify the installed kernel version against the distribution or vendor advisory once available. After remediation, reboot into the fixed kernel, confirm the old vulnerable kernel is not running, and verify that ADM1266 monitoring functionality still works if the hardware is required.

Typical attack path

1. Gain local code execution on a Linux system that includes and uses the vulnerable ADM1266 PMBus hardware monitoring driver.
2. Confirm the adm1266 driver is loaded or that ADM1266 PMBus/GPIO functionality is reachable.
3. Invoke GPIO or hwmon interfaces that cause gpiolib to call the driver's get_multiple operation.
4. Cause adm1266_gpio_get_multiple() to iterate past the end of the valid GPIO mask because of the incorrect PDIO scan limit.
5. Rely on or shape adjacent stack contents so out-of-range bits are interpreted as set.
6. Trigger out-of-bounds writes to the caller-supplied bitmap, causing kernel memory corruption.
7. Use the resulting corruption to crash the kernel or, with additional exploit development, attempt local privilege escalation.

How to detect it

There are no known public exploitation campaigns, named threat actors, or ransomware use associated with this issue. Because exploitation occurs inside the kernel and may not leave application-level traces, retrospective detection should focus on kernel telemetry, crash dumps, and evidence of local users invoking GPIO, hwmon, I2C, or PMBus interfaces shortly before a crash. Review dmesg, journald, syslog, kern.log, auditd, kernel panic reports, kdump/vmcore artifacts, and EDR process telemetry for crashes or memory-safety warnings referencing adm1266, pmbus, gpiolib, gpio_get_multiple, KASAN, out-of-bounds access, stack corruption, or general protection faults. Correlate these events with local login history, sudo activity, container workloads with device access, access to /dev/i2c-* or GPIO sysfs/cdev interfaces, and unusual execution by low-privileged users. Absence of these artifacts does not prove non-exploitation, especially on systems without kernel debug, KASAN, audit, or crash capture enabled.

• adm1266_gpio_get_multiple
• drivers/hwmon/pmbus/adm1266.c
• adm1266
• pmbus
• gpiolib
• gpio_get_multiple
• KASAN: stack-out-of-bounds
• KASAN: slab-out-of-bounds
• BUG: KASAN
• general protection fault
• kernel BUG
• Kernel panic
• Oops:
• /sys/bus/i2c/drivers/adm1266
• /dev/i2c-
• CONFIG_SENSORS_ADM1266

What your security team should do

• Inventory Linux systems, appliances, and embedded platforms that use the ADM1266 PMBus hardware monitoring driver or ADM1266 hardware.
• Prioritize patching affected systems where local users, containers with device access, third-party workloads, or untrusted code execution are present.
• Apply the vendor kernel update containing the adm1266_gpio_get_multiple() bounds fix and reboot into the fixed kernel.
• If patching is delayed and ADM1266 functionality is not needed, disable or unload the adm1266 driver after confirming there is no operational dependency.
• Restrict local shell access and device-interface access on potentially affected systems until remediation is complete.
• Enable kernel crash collection and review recent kernel logs for KASAN, BUG, general protection fault, or panic messages involving adm1266, pmbus, gpiolib, or hwmon.
• Track vendor advisories for exact fixed kernel package versions because affected_products and fixed_versions were not provided in the input.
• Treat any unexplained kernel crash on systems using this driver as potentially security-relevant and preserve crash dumps for analysis.