CVE-2026-64493

What it actually does

This is a local denial-of-service and power-management flaw in the Linux kernel Industrial I/O pressure sensor driver for MPL115 devices. When mpl115_read_raw() handles processed pressure or raw temperature reads, it increments the device runtime power-management reference count with pm_runtime_get_sync(). If the read operation fails, the error path returns without releasing that reference via pm_runtime_put_autosuspend(). Repeated failed reads can accumulate leaked runtime PM references, preventing the device from autosuspending and potentially causing persistent device activity, elevated power use, battery drain, or degraded behavior on systems using the affected sensor driver.

Why it matters to the business

The most likely operational impact is reliability and power degradation on Linux-based systems that include MPL115 pressure sensors, especially embedded, mobile, IoT, industrial, or battery-powered devices. Successful abuse could keep the sensor hardware active and consume unnecessary power, shorten battery life, or contribute to service instability. The current public exploitation likelihood appears low: EPSS is 0.00168, the issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no public exploit maturity is reported.

How an attack unfolds

An attacker needs local ability to trigger reads from the affected Industrial I/O sysfs attributes or another interface that invokes the MPL115 driver's raw-read path. The attacker repeatedly causes pressure or temperature reads to fail, for example by interacting with the sensor while the device or bus is in an error state. Each failed read leaks a runtime PM reference. Over time, the reference count remains elevated and the kernel does not autosuspend the device. The practical result is a resource-management denial of service against the affected hardware component rather than code execution or privilege escalation. There is no indication from the provided data that this vulnerability is being actively exploited by named threat actors.

How to fix it

Update the Linux kernel to a version that includes the upstream fix balancing runtime PM references in the mpl115 driver. If consuming kernels from a Linux distribution, embedded vendor, Android/Yocto BSP, or appliance vendor, apply the vendor-provided kernel update containing the fix. No exact fixed package versions were provided, so track the relevant distribution or device-vendor advisory for the corrected kernel build. If immediate patching is not possible, reduce exposure by disabling or unloading the MPL115 driver where the sensor is not required, restricting local access to IIO sysfs device attributes, limiting untrusted workloads on affected devices, and monitoring for repeated failed reads or abnormal power-management behavior.

How to confirm the fix worked

Confirm the running kernel includes the fixed mpl115 driver change that releases the runtime PM reference on both success and error paths. Validate exposure by checking whether the system has the MPL115 driver loaded or built in and whether IIO device attributes for the MPL115 sensor are present. After updating, perform controlled read-error testing where safe and verify that repeated failed pressure or temperature reads do not prevent runtime autosuspend. Operationally, compare runtime PM status, usage counts, and power behavior before and after remediation to ensure the device can autosuspend normally.

Typical attack path

1. Identify a Linux system using the MPL115 Industrial I/O pressure sensor driver.
2. Obtain local access or an application-level path that can read the affected pressure or temperature IIO attributes.
3. Repeatedly trigger pressure or temperature reads that return errors from the underlying device or bus.
4. Cause each failed read to leak a runtime PM reference.
5. Keep the sensor from autosuspending, resulting in elevated power consumption or degraded device behavior.

How to detect it

Look for evidence of local or application-driven repeated reads of MPL115 Industrial I/O sysfs attributes combined with read failures, persistent runtime PM active state, or abnormal battery/power drain. Useful sources include kernel logs, auditd or eBPF file-access telemetry for sysfs reads, process accounting, power-management telemetry, device runtime PM status files, and application logs from services that poll environmental sensors. Review whether untrusted users, containers, or applications accessed pressure or temperature sensor attributes at high frequency. Kernel logs may show I2C/SPI communication errors, IIO driver errors, or sensor read failures around the same time the device stopped autosuspending. Because this flaw does not create a distinctive file, process, registry key, or network artifact, detection should focus on behavioral patterns: repeated accesses to MPL115 IIO attributes, repeated sensor/bus read errors, and runtime PM usage counts that do not return to zero after failed reads.

• mpl115
• mpl115_read_raw
• /sys/bus/iio/devices/iio:device*/in_pressure_input
• /sys/bus/iio/devices/iio:device*/in_temp_raw
• /sys/bus/iio/devices/iio:device*/power/runtime_status
• /sys/bus/iio/devices/iio:device*/power/runtime_usage
• /sys/bus/iio/devices/iio:device*/power/autosuspend_delay_ms
• industrialio
• iio:device

What your security team should do

• Prioritize remediation for embedded, mobile, IoT, industrial, or battery-powered Linux systems that use MPL115 pressure sensors.
• Apply the vendor or distribution kernel update containing the mpl115 runtime PM reference leak fix once available.
• Inventory systems for MPL115 driver usage, including kernel modules, device tree entries, IIO sysfs devices, and hardware bills of materials.
• Where the sensor is unnecessary, disable the driver or remove access to the affected IIO interface.
• Restrict shell, container, and application access that could repeatedly read IIO sensor attributes on affected devices.
• Monitor for repeated failed reads against MPL115 IIO attributes and for devices that remain runtime-active unexpectedly.
• Treat the issue as lower exploitation urgency than internet-facing remote-code-execution flaws because it is not KEV-listed, has low EPSS, and has no reported public exploit maturity, but still remediate where power reliability is business-critical.