CVE-2026-98659 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: pressure: rohm-bm1390: Return error when read fails
The data reading function ignores the cached error value, and unconditionally returns 0. Return cached 'ret' -value after stopping the measurement so user knows if read failed and data is garbage.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel's Industrial I/O subsystem specifically affects the BM1390 pressure sensor driver within the rohm-bm1390 module. This issue stems from a fundamental flaw in how error conditions are handled during asynchronous hardware operations. When the driver initiates a measurement cycle on the physical sensor, it relies on an interrupt or polling mechanism to determine when data is ready. If this process encounters a failure due to I2C communication errors, device timeouts, or other hardware faults, the underlying read function correctly captures and stores the error code in a local variable typically named ret. However, the subsequent logic that returns the result to the user space ignores this stored error value. Instead of propagating the negative errno code back up the call stack, the function unconditionally returns zero. In Linux kernel programming, returning zero from an IIO read channel operation is conventionally interpreted as a successful retrieval of data with a magnitude of zero or no change, rather than a failure state.
This behavior creates a significant discrepancy between the actual hardware status and what is reported to user-space applications. When a read operation fails due to communication issues, the driver may still populate the output buffer with stale, uninitialized, or garbage data from previous measurements. By returning zero instead of an error code like -EIO or -ENODATA, the kernel masks these underlying failures. Applications relying on this sensor for critical environmental monitoring, industrial automation, or safety-critical systems will interpret the returned value as valid data rather than recognizing that no new measurement was successfully obtained. This lack of proper error propagation prevents applications from implementing appropriate fallback mechanisms, such as retrying the operation, alerting an operator, or switching to a redundant sensor if available.
From a security and reliability perspective, this flaw aligns with CWE-253, which describes incorrect check of condition after call, specifically where the return value is not properly validated before use in subsequent logic that affects system state or data integrity. Furthermore, it relates to CWE-703, improper error handling, as the application layer cannot distinguish between a legitimate zero reading and a failed read operation. In the context of MITRE ATT&CK, while this is primarily a reliability issue rather than an exploit vector for direct compromise, it can contribute to Availability impacts under techniques such as T1499 Endpoint Denial of Service if repeated failures cause applications to crash or enter infinite retry loops due to unexpected data patterns. It also affects Data Integrity (TA0005) because the system provides false confidence in the accuracy of sensor readings without indicating that the data source is compromised by hardware faults.
The operational impact extends beyond simple data inaccuracies. In systems where pressure sensors are used for overpressure protection or leak detection, accepting garbage data as valid zero values could lead to catastrophic failures if a real event occurs but the driver fails to report it correctly due to masking errors. Conversely, if the garbage data happens to be non-zero, it might trigger false alarms leading to unnecessary shutdowns or maintenance actions. For developers and system integrators, this means that monitoring tools may not detect sensor degradation or communication bus issues until a more severe failure occurs. The lack of explicit error reporting hinders debugging efforts and complicates root cause analysis when intermittent connectivity problems arise in the I2C bus connecting the host processor to the BM1390 chip.
To mitigate these risks, it is imperative that software relying on this driver implements robust validation logic where possible, although the primary fix must reside within the kernel itself. The recommended mitigation involves updating the Linux kernel to a version where the rohm-bm1390 driver has been patched to correctly return the cached error code when read operations fail. This ensures that user-space applications receive standard POSIX error codes indicating I/O failure rather than misleading zero values. Until such an update is applied, administrators should monitor system logs for signs of hardware communication errors and consider implementing application-level timeouts or checksums if the data format allows it to detect anomalies in sensor readings. Regular kernel updates remain the most effective strategy for addressing these types of driver-level logic flaws that compromise data integrity and operational visibility.