CVE-2026-89937 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: chemical: sgp30: Handle IAQ thread creation failure
kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel driver for the Sensirion SGP30 chemical sensor contains a critical logic flaw in its initialization sequence that can lead to system instability or crashes during device removal operations. The specific vulnerability resides within the sgp_probe function, which is responsible for setting up the hardware and starting background threads required for proper operation. Specifically, the driver attempts to create an IAQ (Indoor Air Quality) calculation thread using the kthread_run API. This kernel function can fail under various conditions such as memory pressure or resource exhaustion, in which case it returns a pointer encoded with an error code rather than a valid task structure.
The core technical flaw is that the sgp_probe function incorrectly treats this error return value as a successful initialization result. Instead of checking for failure and aborting the probe process, the driver stores the invalid error pointer into its internal data structures and proceeds to register the device with the kernel subsystem. This creates an inconsistent state where the hardware appears fully initialized and available to user space applications, but the essential background thread responsible for processing sensor data is missing. The code assumes that if sgp_probe returns zero (success), all necessary components including the IAQ thread are operational.
This design error leads to a severe operational impact when the device driver is unloaded or the hardware is removed from the system. During the cleanup phase, the sgp_remove function attempts to stop the previously created thread by passing the stored pointer to kthread_stop. Since this pointer actually contains an encoded negative error code rather than a valid task_struct address, the kernel interprets it as a legitimate memory address. Passing such invalid pointers to kernel synchronization primitives results in undefined behavior, typically manifesting as a null pointer dereference or general protection fault that crashes the operating system. This represents a denial of service vulnerability triggered by normal driver lifecycle events.
From a classification perspective, this issue aligns with CWE-252 unchecked return value and CWE-476 NULL pointer dereference in its potential manifestation during removal. The failure to validate the output of kthread_run violates fundamental defensive programming principles required for robust kernel development. In terms of attack vectors, while not directly exploitable by remote attackers without prior access, this flaw can be triggered locally by a user with sufficient privileges to load and unload kernel modules or by automated systems that manage device hotplugging events. The vulnerability falls under the MITRE ATT&CK technique of System Service Discovery followed by potential disruption via resource exhaustion leading to instability.
The resolution involves modifying the sgp_probe function to properly check the return value of kthread_run for errors before proceeding with device registration. If the thread creation fails, the probe function must immediately return the error code rather than continuing execution. This ensures that the driver is not registered in an incomplete state and prevents the subsequent call to kthread_stop from receiving invalid data during removal. Developers should implement strict validation of all kernel API calls that can fail due to resource constraints or other transient conditions. Additionally, adding comprehensive logging for thread creation failures aids in debugging similar issues across other drivers within the industrial I/O subsystem. Maintaining consistency between initialization success and cleanup requirements is essential for preventing these types of lifecycle-related vulnerabilities in Linux kernel modules.