CVE-2026-64083

What it actually does

This is a Linux kernel information disclosure flaw in the ADM1266 PMBus hardware-monitoring/GPIO driver. The affected GPIO accessors read a two-byte GPIO or PDIO status value using an SMBus block read but only checked for a negative error return, not whether the device actually returned the expected two bytes. If a device, firmware fault, bus error, or malicious I2C/SMBus slave returns a zero- or one-byte response, the driver may combine returned data with uninitialized kernel stack bytes and expose a small amount of kernel memory to userspace through gpiolib interfaces such as sysfs or GPIO character-device ioctls. The practical leak is limited in size per request but can be repeated if an attacker can trigger short reads and access the affected GPIO interface.

Why it matters to the business

Systems using the affected Linux kernel driver with ADM1266-compatible PMBus/GPIO hardware may leak small fragments of kernel memory to local users or processes with access to the relevant GPIO interfaces. This is unlikely to cause immediate standalone compromise, but kernel memory disclosure can weaken platform security, expose sensitive runtime data, and assist exploitation of other kernel vulnerabilities by reducing uncertainty around memory contents or layout. The low EPSS score and lack of known KEV listing indicate no current evidence of broad exploitation, but organizations running Linux on embedded, industrial, server-management, or hardware-control platforms should treat it as a defense-in-depth kernel update priority.

How an attack unfolds

An attacker needs a system running an affected Linux kernel with the ADM1266 PMBus/GPIO driver active and a path to query the affected GPIO lines through userspace interfaces. The attacker also needs the underlying device, bus, firmware, or a hostile/slaved peripheral to produce a short SMBus block-read response for GPIO_STATUS or PDIO_STATUS. When the driver receives a zero- or one-byte response, it still constructs a two-byte pin-status value using uninitialized stack memory for the missing byte or bytes. The resulting value is returned through gpiolib, allowing the attacker to observe leaked kernel stack bits. Repeating the operation may disclose additional small memory fragments that could be used to support further local kernel exploitation or bypass mitigations in combination with other bugs.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or upstream stable branch that includes the ADM1266 PMBus driver fix rejecting short block-read responses and returning an I/O error instead. Because no product-specific fixed versions were provided, use vendor kernel advisories and package changelogs for CVE-2026-64083 or verify that the patch adding a length check to adm1266_gpio_get() and adm1266_gpio_get_multiple() is present. Where immediate patching is not possible, reduce exposure by disabling or unloading the affected adm1266 driver if the hardware is not required, restricting access to GPIO sysfs and /dev/gpiochip* interfaces to trusted users and services only, and limiting physical or logical ability for untrusted devices to interact with the I2C/SMBus segment.

How to confirm the fix worked

Confirm remediation by checking that the running kernel package includes the vendor fix for CVE-2026-64083 or that the source for drivers/hwmon/pmbus/adm1266.c validates the SMBus block-read length before using read_buf[0] and read_buf[1]. On live systems, verify whether the adm1266 driver is loaded or bound by checking loaded modules, sysfs device bindings, and kernel configuration. Confirm that unprivileged users cannot access the relevant GPIO character devices or legacy sysfs GPIO paths unless explicitly required. For regression testing, a controlled I2C/SMBus test device or fault-injection harness should return zero- and one-byte block-read responses and confirm that the patched kernel returns an error rather than exposing a GPIO value.

Typical attack path

1. Identify a Linux system with the ADM1266 PMBus/GPIO driver present and bound to compatible hardware.
2. Gain local access or code execution with permission to query the exposed GPIO interface through sysfs or the GPIO character device.
3. Cause or wait for short SMBus block-read responses from the ADM1266 GPIO/PDIO status registers, such as through a faulty device, bus disturbance, firmware behavior, or a malicious peripheral on the bus.
4. Repeatedly request GPIO status values from userspace.
5. Collect returned status values that include bits derived from uninitialized kernel stack memory.
6. Use the leaked information directly for reconnaissance or as an aid to exploit a separate kernel vulnerability.

How to detect it

There is no reliable remote indicator of exploitation because the issue leaks small kernel stack fragments through normal local GPIO read paths. To look for possible prior abuse, review local audit logs, process accounting, shell history, EDR telemetry, and application logs for unexpected or repeated access to GPIO interfaces such as /dev/gpiochip* or legacy /sys/class/gpio paths on systems with the adm1266 driver active. Correlate such access with kernel logs showing I2C/SMBus read failures, PMBus communication errors, device resets, or bus instability around the same time. On systems with auditd, search for open/ioctl/read activity against GPIO character devices by unusual users or processes. Treat repeated GPIO polling combined with I2C/SMBus errors as suspicious but not conclusive, because hardware faults can generate similar symptoms. If a hostile peripheral or bus fault is suspected, preserve kernel logs, audit records, process execution telemetry, and hardware-management logs for timeline analysis.

• /dev/gpiochip
• /sys/class/gpio
• adm1266
• drivers/hwmon/pmbus/adm1266.c
• GPIO_STATUS
• PDIO_STATUS
• i2c_smbus_read_block_data

What your security team should do

• Prioritize inventory: identify Linux systems that load the adm1266 PMBus/GPIO driver or contain ADM1266-compatible hardware.
• Apply the appropriate vendor kernel update once available for all affected systems, especially embedded, hardware-management, industrial-control, and server-platform devices.
• If patching is delayed, restrict access to /dev/gpiochip* and legacy GPIO sysfs interfaces to trusted users and services only.
• Disable or blacklist the adm1266 driver on systems where the hardware functionality is not required.
• Review I2C/SMBus topology and physical access controls for platforms where untrusted or field-replaceable devices could influence bus responses.
• Monitor kernel/vendor advisories because no known exploited-in-the-wild status is currently reported, but kernel information leaks can become more important when chained with other vulnerabilities.