CVE-2026-64499

What it actually does

This flaw is a Linux kernel resource-management bug in the TI ADS1119 Industrial I/O ADC driver. During IIO buffer pre-enable, the driver calls pm_runtime_resume_and_get() to resume the device, then attempts an I2C SMBus write to start conversion. If that I2C write fails, the error path returns without dropping the runtime power-management reference. Because the matching post-disable callback is not invoked when pre-enable fails, the runtime PM usage counter remains elevated and the ADC device may remain permanently runtime-active until reboot, driver reload, or manual recovery. The impact is primarily denial of service, power drain, thermal/battery impact, and device power-state inconsistency rather than code execution or privilege escalation.

Why it matters to the business

Organizations using Linux systems with TI ADS1119 ADC hardware may experience unnecessary power consumption, reduced battery life, thermal stress, or degraded reliability if the sensor device is repeatedly driven into this failure path. The practical risk is highest for embedded, industrial, IoT, edge, and battery-powered systems where sensor availability and power management are operationally important. Public exploitation probability appears low based on the very low EPSS score, no known exploited status, and no reported exploit maturity, but affected fleets should still pick up the kernel fix through normal maintenance because the issue can create persistent operational instability.

How an attack unfolds

An attacker would first need access to a Linux system that uses the ti-ads1119 IIO ADC driver and permits interaction with the relevant IIO buffer controls, or otherwise be able to trigger the buffer pre-enable path. The attacker then causes or waits for an I2C SMBus write failure while enabling the triggered buffer. When the write fails, the vulnerable driver exits without releasing the runtime PM reference it acquired earlier. Repeating this action can leave the ADS1119 device runtime-active indefinitely, increasing power draw and potentially contributing to battery exhaustion, thermal issues, or sensor subsystem instability. There is no indication from the available information that this provides arbitrary code execution, kernel memory corruption, or direct privilege escalation.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the ti-ads1119 driver runtime PM reference leak. If using a distribution kernel, apply the vendor kernel security or stable update that backports the fix. If building kernels internally, ensure the driver error path drops the runtime PM reference when i2c_smbus_write_byte() fails in ads1119_triggered_buffer_preenable(). Where immediate patching is not possible, reduce exposure by disabling unused ADS1119 hardware, unloading or blacklisting the ti-ads1119 driver where operationally safe, restricting local access to IIO sysfs buffer controls, and monitoring for repeated IIO buffer enable failures or abnormal device power-state behavior.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream patch for the ti-ads1119 runtime PM reference leak. On affected hardware, validate by inducing a controlled I2C transfer failure during IIO buffer enable in a test environment and confirming the runtime PM usage count is released and the device can return to a suspended/runtime-idle state. Also verify that enabling and disabling the IIO buffer no longer leaves the ADS1119 device runtime-active after a pre-enable failure. For production validation, check kernel package versions against distribution advisories and inspect driver source or symbol builds where custom kernels are used.

Typical attack path

1. Identify a Linux system using the TI ADS1119 ADC through the ti-ads1119 Industrial I/O driver.
2. Obtain local or application-level ability to interact with the IIO device buffer controls, such as enabling the triggered buffer through sysfs or an application interface.
3. Trigger the ads1119_triggered_buffer_preenable() path by attempting to enable buffered sampling.
4. Cause or coincide with an I2C SMBus write failure during conversion setup.
5. Rely on the vulnerable error path to leak the runtime PM reference.
6. Repeat the operation if necessary to keep the ADC device runtime-active and increase operational impact such as power drain or instability.

How to detect it

To assess whether this issue has already been exercised, focus on local system and kernel telemetry rather than network indicators. Review kernel logs for ADS1119, IIO, I2C, and runtime power-management errors around times when applications enabled IIO buffered sampling. Inspect auditd, shell history, EDR, or application logs for repeated writes to IIO buffer enable controls, especially from unexpected users or processes. On embedded systems, compare power, battery, and thermal telemetry against normal baselines and look for ADC devices remaining runtime-active after failed buffer-enable attempts. For forensics, check whether the ti-ads1119 driver is loaded, whether matching IIO device sysfs entries exist, and whether the device runtime PM status remains active when no sampling workload is expected. There are no known public exploit-specific payloads or threat-actor indicators for this issue based on the supplied intelligence.

• ti-ads1119
• ads1119
• ads1119_triggered_buffer_preenable
• i2c_smbus_write_byte
• /sys/bus/iio/devices/iio:device*/buffer/enable
• /sys/bus/iio/devices/iio:device*/buffer
• /sys/bus/iio/devices/iio:device*/power/runtime_status
• /sys/bus/i2c/drivers/ads1119
• /sys/bus/i2c/drivers/ti-ads1119
• industrialio
• iio:device
• runtime_status: active

What your security team should do

• Prioritize remediation for embedded, industrial, IoT, edge, and battery-powered Linux systems that include TI ADS1119 ADC hardware.
• Apply the relevant Linux kernel or distribution update once available; for custom kernels, backport the driver fix directly.
• Inventory systems for use of the ti-ads1119 driver and ADS1119-compatible IIO devices before treating this as a fleet-wide emergency.
• Restrict write access to IIO buffer control interfaces to trusted users and services only.
• Monitor kernel logs and power-management telemetry for repeated I2C write failures, IIO buffer enable failures, or devices remaining runtime-active unexpectedly.
• If patching is delayed and the ADC is not required, disable the device tree entry, unload the module, or blacklist the driver after validating operational impact.
• Do not treat this as likely remote code execution; focus response on reliability, power management, and local misuse scenarios.