CVE-2026-53387

What it actually does

This vulnerability is an out-of-bounds array access in the Linux kernel VEML6075 light sensor driver under the Industrial I/O subsystem. The driver uses a value derived from the VEML6075_CONF_IT register as an index into the veml6075_it_ms array, which contains 5 elements, while the register field can produce values 0 through 7. If a reserved value of 5, 6, or 7 is observed, the driver can read past the end of the array. In practical terms, this can lead to kernel memory disclosure and/or a kernel crash, depending on kernel build options, memory layout, compiler behavior, and how the invalid value is triggered. The issue is local attack surface and requires low privileges; it is most relevant on systems where the VEML6075 sensor driver is present and the device, bus, or register state can be influenced through misconfiguration, a faulty peripheral, bus corruption, or a malicious/compromised local component.

Why it matters to the business

Successful exploitation could cause affected Linux systems to crash or expose sensitive kernel memory, disrupting availability of embedded, IoT, industrial, mobile, or specialized Linux devices that use the VEML6075 ultraviolet light sensor driver. Because exploitation requires local access or the ability to influence the attached sensor/bus state, and there is no known public exploit, KEV listing, or ransomware association, broad internet-scale risk is low. However, organizations that operate Linux-based appliances, edge devices, or systems with physical sensors should treat this as a kernel hardening and reliability issue, especially where device availability is operationally important.

How an attack unfolds

An attacker first needs local execution capability or another path to influence the VEML6075 sensor register state, such as access to sensor configuration interfaces, a compromised peripheral, an emulated device, bus fault injection, or a misprogrammed I2C-connected component. The attacker causes the VEML6075_CONF_IT field to return a reserved value of 5, 6, or 7. When the kernel driver reads the sensor configuration and uses that value as an index into the veml6075_it_ms array, the driver accesses memory beyond the array bounds. Depending on runtime conditions, this may result in an information leak from adjacent kernel memory, a kernel oops, or a denial-of-service crash. The upstream fix adds bounds validation and returns an error instead of dereferencing an invalid array index.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the fix for the VEML6075 driver bounds check. If a fixed package is not yet available from the operating system or device vendor, apply the upstream patch that validates the veml6075_it_ms index and returns -EINVAL for out-of-range values. As interim mitigation, disable or unload the VEML6075 driver where it is not required, remove unneeded device-tree or ACPI bindings for the sensor, restrict local access to sensor and I2C interfaces, and prevent untrusted users from loading kernel modules or accessing hardware-management interfaces. For embedded products, include this fix in the next kernel BSP or firmware release and prioritize devices that expose physical sensor buses or allow local shell access.

How to confirm the fix worked

Confirm that the running kernel includes the patched VEML6075 driver logic that checks the VEML6075_CONF_IT-derived index before accessing veml6075_it_ms. Validate vendor advisories or package changelogs for the applicable kernel build. On systems where kernel source or debug symbols are available, verify that drivers/iio/light/veml6075.c contains a bounds check that rejects indexes greater than or equal to the number of veml6075_it_ms elements. Confirm whether the driver is present or loaded by checking kernel configuration, loaded modules, device tree/ACPI enumeration, and IIO device registration. After patching or mitigation, test that normal light sensor readings still work and review kernel logs for absence of out-of-bounds, UBSAN, KASAN, kernel oops, or panic messages associated with veml6075.

Typical attack path

1. Gain local access to a Linux system using or exposing the VEML6075 light sensor driver, or gain the ability to influence the attached sensor/I2C bus state.
2. Manipulate, fault, emulate, or misconfigure the VEML6075 configuration register so the integration-time field resolves to a reserved value of 5, 6, or 7.
3. Trigger a driver code path that reads the sensor configuration and computes the integration-time index.
4. Cause the driver to use the invalid value as an index into the veml6075_it_ms array.
5. Leverage the resulting out-of-bounds access to crash the kernel or potentially expose adjacent kernel memory, depending on system conditions.

How to detect it

To determine whether this was already triggered, review kernel and system logs for crashes, warnings, or memory-safety reports involving the VEML6075 driver or Industrial I/O subsystem. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops, kdump/vmcore analysis, KASAN/UBSAN reports, and device-management telemetry from embedded fleets. Look for kernel oops, panic, general protection fault, slab out-of-bounds, UBSAN array-index-out-of-bounds, or KASAN out-of-bounds-read messages referencing veml6075, veml6075_it_ms, or drivers/iio/light/veml6075.c. Correlate events with local user activity, module loading, I2C bus errors, sensor read operations, unusual sysfs access under IIO device paths, device-tree changes, firmware updates, peripheral replacement, or physical maintenance. There are no known public exploit artifacts, threat actors, or ransomware campaigns tied to this issue, so detection should focus on kernel fault evidence and abnormal sensor/bus behavior rather than network indicators.

• drivers/iio/light/veml6075.c
• veml6075
• veml6075_it_ms
• UBSAN: array-index-out-of-bounds
• KASAN: out-of-bounds
• out-of-bounds in veml6075
• kernel BUG at drivers/iio/light/veml6075.c
• Oops:
• general protection fault
• Kernel panic
• iio: light: veml6075
• /sys/bus/iio/devices/
• /sys/bus/i2c/devices/

What your security team should do

• Inventory Linux systems, appliances, and embedded devices that include or load the VEML6075 Industrial I/O light sensor driver.
• Prioritize remediation on systems where the sensor is physically present, where local users are allowed, or where I2C/sensor interfaces are exposed to untrusted code or peripherals.
• Apply vendor-provided kernel updates or firmware updates that include the bounds-check fix; if vendor fixes lag, evaluate applying the upstream patch in custom kernel builds.
• Disable or blacklist the VEML6075 driver on systems that do not require it.
• Restrict local hardware access paths, including I2C device nodes, debugfs/sysfs interfaces, and kernel module loading, to trusted administrators only.
• Monitor kernel logs for oops, panic, KASAN, UBSAN, or IIO/veml6075-related errors that may indicate attempted triggering or hardware faults.
• Because EPSS is low, exploit maturity is listed as none, and the issue is not in CISA KEV, handle through normal kernel maintenance unless affected devices are safety-critical or availability-sensitive.