CVE-2026-43355

What it actually does

This flaw is a local denial-of-service issue in the Linux kernel bh1780 ambient light sensor driver under the Industrial I/O subsystem. On a failed read path, the driver increments the device PM runtime reference count with pm_runtime_get_sync() but does not reliably decrement it, causing a runtime power-management reference leak. Repeated triggering can prevent the affected device from autosuspending and may contribute to resource exhaustion, abnormal power consumption, or degraded system availability. The CVSS vector indicates local access with low complexity and low privileges, with no confidentiality or integrity impact but potentially high availability impact.

Why it matters to the business

Systems using the affected Linux kernel driver may experience reduced availability, increased power usage, battery drain, device instability, or service disruption if a local low-privileged user or process repeatedly triggers the faulty driver path. This is most relevant to Linux deployments that include the bh1780 light sensor driver, such as embedded, mobile, IoT, kiosk, or hardware-integrated systems. The issue is not listed in CISA KEV, has no known ransomware association, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, it can still matter in shared, multi-user, or physically accessible Linux environments where local denial of service is a concern.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel with the bh1780 light sensor driver present and accessible. The attacker identifies the relevant Industrial I/O sysfs interface or device node exposed for the sensor. They then repeatedly perform read operations that cause the driver's read path to fail after pm_runtime_get_sync() has incremented the runtime PM reference count. Because the vulnerable error path fails to release the runtime PM reference, each failed operation can leave the device in an elevated power-management state. Over time, repeated triggering may prevent autosuspend, increase power consumption, and contribute to availability degradation or instability. Exploitation does not provide code execution or privilege escalation by itself; its impact is availability-focused and depends on the affected hardware and driver exposure.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the bh1780 driver PM runtime reference leak. Because no specific fixed package versions were provided, use the fixed kernel release supplied by the operating system vendor or distribution security advisory. For source-based or embedded builds, apply the kernel patch that moves pm_runtime_put_autosuspend() before the read error check in the iio/light/bh1780 driver so the PM runtime reference is released after pm_runtime_get_sync() regardless of success or failure. If immediate patching is not possible, mitigate by disabling or unloading the bh1780 driver where not required, restricting local access to relevant Industrial I/O sysfs/device interfaces, and limiting untrusted local shell or application access on systems with the affected hardware.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream fix for the bh1780 driver. Validate exposure by checking whether the bh1780 driver is built, loaded, or bound to hardware, and whether Industrial I/O sensor interfaces are accessible to non-privileged users. On patched systems, repeated failed reads against the bh1780 sensor interface should not cause persistent PM runtime reference growth or prevent autosuspend. Review kernel package changelogs or source code to verify that pm_runtime_put_autosuspend() is executed after pm_runtime_get_sync() even when the read operation returns an error. For embedded builds, compare the deployed driver source against the fixed implementation.

Typical attack path

1. Gain local low-privileged access to a Linux system using an affected kernel and the bh1780 light sensor driver.
2. Determine whether the bh1780 Industrial I/O device is present through sysfs, udev, loaded modules, or kernel logs.
3. Access the exposed sensor read interface or associated device node as permitted by local permissions.
4. Trigger read failures repeatedly so the driver's error path leaks PM runtime references.
5. Continue the activity until the device fails to autosuspend, power usage increases, or system/device availability is degraded.

How to detect it

To determine whether exploitation may have occurred, review local system activity rather than network telemetry, because the flaw requires local access. Collect kernel logs, audit logs, syslog/journald entries, udev events, and process execution history around times of unexplained power drain, device instability, or sensor malfunction. Look for repeated access to Industrial I/O sysfs paths associated with bh1780, repeated read errors from the bh1780 driver, abnormal persistence of runtime power-management active states, and suspicious local processes repeatedly reading sensor attributes. On systems with auditd or eBPF telemetry, search for high-frequency open/read operations against /sys/bus/iio/devices/ paths and bh1780-bound device paths. Also review shell history, cron jobs, systemd timers, containers, or untrusted local applications that may have scripted repeated sensor reads. There are no public reports of known exploitation, named threat actors, or ransomware use for this issue, so detections should focus on anomalous local behavior and affected-driver artifacts rather than known attacker infrastructure.

• bh1780
• iio: light: bh1780
• /sys/bus/iio/devices/
• /sys/bus/iio/drivers/bh1780
• /sys/bus/i2c/drivers/bh1780
• pm_runtime_get_sync
• pm_runtime_put_autosuspend
• runtime_status
• runtime_active_time
• runtime_suspended_time

What your security team should do

• Prioritize patching on Linux systems that expose bh1780 light sensor hardware, especially embedded, IoT, kiosk, mobile, or shared multi-user devices.
• Inventory systems for the bh1780 driver using kernel module listings, device-tree or ACPI hardware descriptions, sysfs Industrial I/O entries, and vendor kernel configurations.
• If the sensor is not needed, disable the bh1780 kernel module or remove it from custom kernel builds.
• Restrict local user and application access to Industrial I/O device files and sysfs attributes where operationally feasible.
• Monitor affected device classes for unusual battery drain, power-management anomalies, kernel warnings, or repeated sensor read failures.
• Treat this as lower urgency for general-purpose servers without the bh1780 driver or hardware, given the local attack requirement, low EPSS, no known exploit maturity, and no KEV listing.