CVE-2026-64494

What it actually does

This is a Linux kernel denial-of-service condition in the GP2AP002 ambient light sensor IIO driver. During a raw lux-value read, the driver increments a runtime power-management reference with pm_runtime_get_sync(), but on a sensor read failure it returns without calling pm_runtime_put_autosuspend(). Each failed read can leak a runtime PM reference, keeping the device permanently active and preventing autosuspend. The practical technical effect is power-management resource leakage rather than code execution, privilege escalation, or data disclosure.

Why it matters to the business

Systems using the affected GP2AP002 light sensor driver may experience unnecessary power draw, reduced battery life, increased heat, and degraded reliability if the vulnerable error path is repeatedly triggered. The risk is most relevant to embedded, mobile, IoT, appliance, and edge Linux devices where power management and thermal behavior are operationally important. The vulnerability is not currently listed in CISA KEV, has low EPSS likelihood, and has no known public exploit maturity, so urgency is lower than remotely exploitable kernel flaws, but it should still be fixed during normal kernel maintenance for affected device fleets.

How an attack unfolds

An attacker or untrusted local workload would need access to an affected Linux system exposing the GP2AP002 light sensor through the Industrial I/O sysfs interface or another path that invokes gp2ap002_read_raw(). The attacker repeatedly triggers raw light sensor reads while the underlying sensor read operation fails, causing gp2ap002_get_lux() to return an error. In vulnerable kernels, that error path exits before releasing the runtime PM reference, so the device remains marked as in use. Repeating the action can keep the sensor from autosuspending indefinitely, increasing power consumption and potentially contributing to battery drain, thermal stress, or device instability. This is a local denial-of-service style issue and does not provide direct remote compromise or arbitrary kernel execution based on the published description.

How to fix it

Apply a kernel version or vendor kernel update that includes the GP2AP002 driver fix ensuring the runtime PM reference is released on the read-error path. If no fixed package version is available from the platform vendor yet, track the upstream Linux kernel patch for drivers/iio/light/gp2ap002.c and consume it through the supported vendor kernel channel rather than applying ad hoc source changes where possible. As interim mitigations, restrict untrusted local access to IIO sensor sysfs nodes, disable or unload the gp2ap002 driver if the sensor is not required, and use device policy controls to prevent untrusted applications from repeatedly polling the light sensor.

How to confirm the fix worked

Confirm whether the running kernel includes the patched gp2ap002_read_raw() error handling path that always reaches the cleanup block and calls pm_runtime_put_autosuspend() after pm_runtime_get_sync(). Validate exposure by checking whether the gp2ap002 driver is present, loaded, or bound to hardware. On representative devices, exercise light sensor reads under normal and fault conditions and verify that runtime PM state returns to suspended or autosuspended after reads complete. Review vendor kernel changelogs, package metadata, or source diffs for the GP2AP002 runtime PM leak fix.

Typical attack path

1. Identify a Linux device using the GP2AP002 ambient light sensor driver.
2. Obtain local ability to read the exposed IIO light sensor raw value, commonly through sysfs or an application interface that reaches the same driver path.
3. Trigger or wait for sensor read failures affecting gp2ap002_get_lux().
4. Repeatedly perform raw lux reads so gp2ap002_read_raw() takes the vulnerable error path.
5. Cause runtime PM references to leak, preventing the sensor from autosuspending.
6. Sustain elevated power usage or device wakefulness, contributing to battery drain, heat, or reliability degradation.

How to detect it

Look for evidence of abnormal or repeated access to GP2AP002 IIO sensor raw values, especially paired with sensor read errors, elevated power consumption, or runtime PM state that remains active indefinitely. Useful sources include kernel logs, dmesg, journald, auditd records for sysfs reads, endpoint telemetry for processes repeatedly reading IIO files, and power-management telemetry from affected devices. For post-incident review, compare the runtime PM state and usage counters for the sensor device before and after sensor reads, and investigate processes that frequently access IIO light sensor attributes. Because the flaw does not create a distinctive payload, reliable detection is behavioral: repeated sensor reads, read failures, and a device that fails to autosuspend.

• gp2ap002
• gp2ap002_read_raw
• gp2ap002_get_lux
• drivers/iio/light/gp2ap002.c
• /sys/bus/iio/devices/iio:device
• in_illuminance_raw
• /sys/bus/iio/devices/iio:device*/in_illuminance_raw
• /sys/bus/i2c/devices/*/power/runtime_status
• /sys/bus/i2c/devices/*/power/runtime_usage
• runtime_status: active

What your security team should do

• Inventory Linux-based products and device images for use of the GP2AP002 ambient light sensor driver.
• Prioritize remediation for battery-powered, thermally constrained, kiosk, mobile, IoT, and edge devices where persistent wakefulness has operational impact.
• Apply vendor kernel updates when available; if maintaining a custom kernel, backport the upstream GP2AP002 runtime PM cleanup fix.
• Restrict access to IIO sysfs sensor interfaces to trusted users and services only.
• Monitor affected devices for abnormal battery drain, elevated temperature, or runtime PM states that remain active after sensor reads.
• Treat this as a maintenance-priority denial-of-service issue unless local untrusted code execution is a realistic threat model for the affected device class.