CVE-2025-40114 in Linux
Summary
by MITRE • 04/18/2025
In the Linux kernel, the following vulnerability has been resolved:
iio: light: Add check for array bounds in veml6075_read_int_time_ms
The array contains only 5 elements, but the index calculated by veml6075_read_int_time_index can range from 0 to 7, which could lead to out-of-bounds access. The check prevents this issue.
Coverity Issue CID 1574309: (#1 of 1): Out-of-bounds read (OVERRUN) overrun-local: Overrunning array veml6075_it_ms of 5 4-byte elements at element index 7 (byte offset 31) using index int_index (which evaluates to 7)
This is hardening against potentially broken hardware. Good to have but not necessary to backport.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 02/16/2026
The vulnerability CVE-2025-40114 represents a critical out-of-bounds memory access issue within the Linux kernel's IIO (Industrial I/O) subsystem, specifically affecting the veml6075 light sensor driver. This flaw exists in the veml6075_read_int_time_ms function where an array containing only five elements is accessed using an index that can theoretically range from zero to seven, creating a potential buffer overrun condition. The Coverity static analysis tool identified this issue as CID 1574309, categorizing it as an overrun-local problem that specifically targets the veml6075_it_ms array of 5 four-byte elements. When the function calculates an index value of seven, it attempts to access byte offset 31 in an array that only provides space for four bytes after the initial five elements, representing a clear violation of memory boundary constraints.
This vulnerability stems from improper input validation within the sensor driver's configuration handling mechanism, where the veml6075_read_int_time_index function generates index values that exceed the predefined array bounds. The issue demonstrates a classic buffer overflow scenario where the index calculation logic fails to properly constrain the valid range of values to match the actual array dimensions. The root cause lies in the lack of bounds checking between the calculated index value and the physical array size, creating a potential attack surface where malicious input could trigger memory corruption. This type of vulnerability falls under CWE-129, which specifically addresses insufficient validation of array indices, and represents a common class of memory safety issues that can lead to system instability or potential privilege escalation.
The operational impact of this vulnerability extends beyond simple memory corruption, as it can potentially lead to system crashes, data corruption, or in more severe scenarios, arbitrary code execution within kernel space. When the out-of-bounds access occurs, it may overwrite adjacent memory locations, potentially corrupting kernel data structures or interfering with critical system operations. The vulnerability affects systems utilizing the veml6075 light sensor through the IIO subsystem, which is commonly found in embedded devices, IoT systems, and various industrial monitoring applications. From an ATT&CK framework perspective, this vulnerability could be leveraged as part of a privilege escalation technique, specifically under T1068, which involves exploiting vulnerabilities in the kernel or system services. The issue is particularly concerning in environments where the sensor driver is exposed to untrusted input or where multiple sensor interfaces are present, as it could potentially be chained with other vulnerabilities.
The fix implemented addresses this vulnerability by adding proper bounds checking to prevent the out-of-bounds access scenario. This defensive programming approach ensures that any calculated index value is validated against the actual array dimensions before memory access occurs, effectively preventing the buffer overrun condition. The mitigation strategy aligns with established security practices that emphasize input validation and bounds checking as fundamental defenses against memory corruption vulnerabilities. While the vulnerability description notes that this hardening measure is "good to have but not necessary to backport," the presence of such a flaw in production kernel versions represents a significant security risk that should be addressed in all affected systems. The solution demonstrates proper secure coding practices that should be implemented across all kernel subsystems, particularly those handling sensor data and device configuration parameters, and serves as a reminder of the importance of rigorous code review processes and static analysis tools in preventing memory safety issues.