CVE-2026-43476

What it actually does

This is a Linux kernel memory-corruption flaw in the SPS30 I2C chemical sensor driver. The vulnerable code uses sizeof(num), which resolves to the platform size of size_t, typically 8 bytes on 64-bit systems, instead of the intended 4-byte big-endian measurement element size. When measurement data is read from the device, the driver can use an incorrect buffer size, potentially causing an out-of-bounds read or write in kernel context. Because exploitation occurs in the kernel, successful abuse could lead to kernel memory corruption, denial of service, information disclosure, or local privilege escalation, depending on system configuration, driver reachability, and exploit reliability.

Why it matters to the business

Systems that load or expose the affected Linux SPS30 I2C sensor driver may be at risk of local compromise or instability. The most likely operational impact is a kernel crash or device malfunction, but the CVSS assessment indicates that privilege escalation and disclosure of sensitive kernel memory are also possible. The issue is not known to be exploited in the wild, is not in CISA KEV, has no known public exploit maturity, and has a low EPSS score, so urgency is lower than for remotely exploitable or actively exploited kernel flaws. However, organizations using embedded Linux, industrial monitoring systems, IoT gateways, environmental sensors, or custom hardware with SPS30 particulate sensors should prioritize validation and kernel updates because affected devices may be difficult to monitor and recover if they crash.

How an attack unfolds

An attacker first needs local access to a system where the affected Linux kernel driver is present, loaded, and reachable through the IIO sensor interface or another path that causes SPS30 I2C measurements to be read. The attacker then triggers measurement reads in a way that exercises sps30_i2c_read_meas(). Because the driver uses the wrong size when handling measurement elements, the kernel may access more bytes than the target buffer element is intended to hold. With sufficient control over timing, repeated triggering, and knowledge of the target kernel build, an attacker may be able to turn the memory corruption into a kernel crash or potentially manipulate kernel memory for privilege escalation. Exploitation is expected to be local and hardware/configuration dependent, and there is currently no evidence of active exploitation or known ransomware use.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the SPS30 I2C driver buffer-size correction. Because no exact fixed package versions were provided, use vendor advisories for the specific distribution, appliance, embedded platform, or kernel branch in use. Prioritize systems where the sps30_i2c module is present, loaded, or built into the kernel. If immediate patching is not possible, mitigate by disabling or unloading the sps30_i2c driver where it is not required, removing access to the affected sensor interface from untrusted local users, restricting access to IIO sysfs device nodes, and limiting local shell access on systems with the affected hardware. For custom kernels, backport the code change that replaces the incorrect sizeof(num) usage with the correct element-size expression, sizeof(*meas), in sps30_i2c_read_meas().

How to confirm the fix worked

Confirm remediation by verifying that the running kernel contains the vendor fix or an equivalent backport for the SPS30 I2C driver. Check the installed and running kernel versions, then compare them against the distribution or hardware vendor advisory. On source-based or custom kernels, inspect the driver implementation and confirm that sps30_i2c_read_meas() uses the measurement element size rather than sizeof(size_t). Validate exposure by checking whether the sps30_i2c module exists or is loaded, whether the affected driver is built into the kernel, and whether IIO devices associated with SPS30 sensors are present under sysfs. After patching or mitigation, confirm that the vulnerable module is no longer present, is updated, or is not reachable by untrusted users, and review kernel logs for absence of new memory-corruption warnings during sensor reads.

Typical attack path

1. Gain low-privileged local access to a Linux system using the affected kernel driver.
2. Confirm that the SPS30 I2C driver is available, loaded, and associated with an exposed IIO device.
3. Trigger repeated sensor measurement reads through the available local interface, such as sysfs or an application that reads IIO measurements.
4. Exercise the vulnerable sps30_i2c_read_meas() code path where the driver uses an incorrect buffer size.
5. Cause kernel memory corruption, leading to a crash, information disclosure, or potentially privilege escalation.
6. If privilege escalation succeeds, establish persistence or access sensitive local data using elevated kernel-derived privileges.

How to detect it

Look for evidence that the vulnerable driver was present and that local users or processes triggered sensor reads around the time of kernel faults. Useful log sources include kernel logs, dmesg output, systemd journal entries for the kernel, crash dumps, kdump/vmcore artifacts, audit logs for local command execution, and file-access telemetry for sysfs IIO device paths. Search for kernel warnings, KASAN reports, stack traces, page faults, oops messages, or panics referencing sps30_i2c, sps30_i2c_read_meas, IIO, or industrialio. Also review local access logs and process accounting for unusual scripts or binaries repeatedly reading IIO measurement attributes. There are no known public exploit-specific indicators, no known active exploitation, and no named threat actors associated with this issue, so detection should focus on driver reachability, repeated triggering behavior, and generic kernel memory-corruption artifacts.

• sps30_i2c
• sps30_i2c_read_meas
• iio: chemical: sps30_i2c
• industrialio
• /sys/bus/iio/devices/iio:device
• KASAN: stack-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: unable to handle page fault
• general protection fault
• kernel BUG
• Oops:
• Call Trace:
• Unable to handle kernel NULL pointer dereference
• sps30

What your security team should do

• Inventory Linux systems, embedded devices, and IoT/industrial platforms that use SPS30 particulate sensors or load the sps30_i2c driver.
• Prioritize patching or kernel backports for systems where the driver is loaded, built in, or exposed to local users.
• If patching is delayed, unload or blacklist the sps30_i2c module where the hardware is not required.
• Restrict local user access to IIO sysfs sensor interfaces and remove unnecessary shell access on embedded or appliance-like systems.
• Monitor kernel logs for crashes, KASAN findings, general protection faults, and warnings involving sps30_i2c_read_meas or sps30_i2c.
• For custom kernels, confirm the exact upstream fix is included rather than relying only on version strings.
• Treat unexplained kernel crashes on systems with this driver as potentially security relevant until logs and access history are reviewed.
• Because this issue is not currently in KEV and has low EPSS, sequence it behind actively exploited remote vulnerabilities, but do not ignore exposed embedded or operational-technology deployments.