CVE-2026-89933 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: pressure: dps310: fix NULL pointer dereference on ACPI probe
When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in "iio->name = id->name" and crashes the kernel during probe.
The IIO device name is always "dps310", so set it directly and drop the now-unused device-id lookup.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified as a null pointer dereference within the Linux kernel's Industrial Input Output subsystem specifically affects the dps310 pressure sensor driver when operating in an ACPI enumeration context. This issue arises during the initial probe phase of the driver, where the system attempts to initialize hardware resources and bind them to the appropriate device handler. The root cause lies in a mismatch between how the I2C client is identified via Advanced Configuration and Power Interface tables versus how the kernel driver expects to identify it through its internal device ID table. When the device is enumerated using the ACPI Hardware Identification string IFX3100, the function i2c_client_get_device_id() fails to find a matching entry in the driver's static i2c_device_id array because that array typically contains entries for Device Tree compatible strings or specific I2C IDs rather than arbitrary ACPI HIDs. Consequently, this lookup function returns NULL instead of a valid pointer to an i2c_device_id structure.
The operational impact of this flaw is immediate and severe during the device initialization process. The dps310_probe() routine proceeds under the assumption that the result from i2c_client_get_device_id() will be a valid, non-null pointer representing the matched driver data. It then attempts to dereference this NULL pointer by assigning id->name to the IIO device name field within the local structure. This invalid memory access triggers a kernel panic or oops, effectively crashing the system or at least preventing the sensor from being initialized and used. For systems relying on ACPI for hardware discovery rather than Device Tree, such as many modern x86 laptops and embedded platforms, this bug renders the dps310 pressure sensor completely non-functional upon boot if the driver is built into the kernel or loaded early in the startup sequence.
From a vulnerability classification perspective, this defect aligns with CWE-476, which denotes a NULL Pointer Dereference. This type of error occurs when software attempts to use a pointer that has not been initialized or has been explicitly set to null, leading to undefined behavior and potential denial of service conditions in the context of kernel-space execution. In terms of attack vectors, while this is primarily an internal stability issue rather than a remote exploit vector, it falls under the broader category of improper input validation where external configuration data ACPI HID strings are not adequately validated before being used for critical memory operations. The ATT&CK framework does not have a direct mapping for kernel probe failures as they are typically considered reliability issues unless exploited in conjunction with other vulnerabilities to achieve privilege escalation or denial of service, but the underlying mechanism is consistent with CWE-476 patterns often seen in driver development errors.
The resolution involves refactoring the probe logic to eliminate reliance on dynamic device ID lookups for naming purposes that do not require such complexity. Since the IIO subsystem expects a specific name format and the dps310 sensor has a fixed identity, the fix hardcodes the device name directly within the probe function rather than retrieving it from a potentially null i2c_device_id structure. This approach simplifies the code path by removing an unnecessary lookup operation that is prone to failure in ACPI-only environments. By setting the name explicitly, the driver becomes more robust against variations in how different firmware implementations expose hardware identifiers.
Mitigation strategies for this vulnerability primarily involve applying the upstream kernel patch that corrects the probe logic. For administrators running unpatched kernels, there are no simple workarounds other than ensuring the dps310 driver is not loaded or blacklisting it if the system relies on ACPI enumeration and cannot tolerate a boot-time crash due to sensor initialization failures. However, since this affects core hardware functionality, disabling the driver may impact applications that rely on pressure data for environmental monitoring or altitude calculations. The long-term mitigation requires maintaining up-to-date kernel versions where such driver-level bugs are routinely identified and corrected through rigorous code review processes focused on pointer validation before dereference operations in device probe routines.