CVE-2026-98661

What it actually does

On failure to read the integration time from the rohm-bu27034 sensor, the driver passes the resulting error code directly into a sleep-time calculation, producing an invalid or extremely large delay that can stall the IIO subsystem or the calling process indefinitely.

Why it matters to the business

A local process that triggers the sensor read failure can hang kernel threads or user-space applications that depend on the light sensor, leading to reduced availability of monitoring or control features on affected Linux systems.

How an attack unfolds

An attacker with local access causes the iio light driver to attempt a read of the integration-time register under conditions that return an error; the driver then computes a sleep duration from that error code, resulting in an effectively infinite delay that blocks further execution in the affected code path.

How to fix it

Update the Linux kernel to a version containing the fix that substitutes the smallest valid integration time when the register read fails; rebuild and deploy the kernel or distribution package containing the corrected rohm-bu27034 driver.

How to confirm the fix worked

Confirm the presence of the patched driver source (check for the conditional that supplies a default integration time on read failure), verify that the module loads without the prior unconditional use of the error code, and test sensor reads under simulated error conditions to ensure finite sleep times.

Typical attack path

1. Obtain local shell or process execution on a system using the rohm-bu27034 driver
2. Trigger or wait for an error condition during integration-time register access
3. Observe or induce the resulting sleep computed from the error code
4. Maintain the condition to sustain the stall in the IIO subsystem

How to detect it

Review kernel logs for repeated entries from the rohm-bu27034 driver around iio read operations; look for processes stuck in uninterruptible sleep while accessing the light sensor sysfs or iio device files.

What your security team should do

• Prioritize kernel updates for any systems exposing the rohm-bu27034 sensor to untrusted local users
• Audit device trees and driver configurations to identify deployments of this sensor
• Monitor upstream stable kernel releases for backports of the fix