CVE-2026-98657 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure
pm_runtime_set_active() failing in probe() jumps to error_unreg_buffer, which only calls iio_triggered_buffer_cleanup() -- it does not undo the iio_device_register() that already succeeded a few lines above. probe() then returns the error, the devm-managed indio_dev is freed, but the iio core still has it registered: the sysfs/chardev nodes stay live and point at freed memory.
Add an error_unreg_dev label that unregisters the iio device before falling through to the existing buffer cleanup, mirroring the teardown order already used in lidar_remove().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel's Industrial I/O subsystem contains a resource management flaw within the pulsed light proximity driver that results in use-after-free conditions and potential system instability. This vulnerability arises from an incorrect error handling path during device probe operations, specifically when power management runtime setup fails. The core issue lies in the asymmetry between registration and cleanup routines, where successful initialization of certain components is not properly reversed upon subsequent failure, leaving kernel data structures in a dangling state that can be accessed by user space or other kernel subsystems long after the underlying memory has been reclaimed.
During the probe function execution, the driver attempts to register an Industrial I/O device using iio_device_register and subsequently configures power management settings via pm_runtime_set_active. If the latter call fails, control flow jumps to a cleanup label designated for buffer unregistration. This specific error path invokes iio_triggered_buffer_cleanup but critically omits the corresponding unregister operation for the previously registered iio device. Consequently, while the driver core frees the managed indio_dev structure due to devm management, the Industrial I/O subsystem retains an internal reference to this now-freed memory block. The sysfs interface nodes and character device entries remain active in the virtual file system hierarchy, pointing directly to deallocated kernel memory regions.
This architectural inconsistency creates a severe security risk classified under CWE-416, Use After Free. An attacker or malicious user space process interacting with the exposed sysfs attributes or chardev interfaces can trigger reads or writes against invalid pointers. Such interactions may lead to information disclosure by leaking sensitive kernel data contained in the freed memory slab, cause kernel panics through null pointer dereferences or general protection faults, or potentially facilitate arbitrary code execution if specific heap layout conditions are met and exploited via controlled overwrites of adjacent metadata structures. The persistence of these live nodes means that even after a failed driver load attempt, the system remains vulnerable until rebooted or the module is forcibly removed with careful unloading procedures that might inadvertently trigger the buggy path again.
The operational impact extends beyond immediate stability concerns to include compliance failures and reliability degradation in embedded systems where such drivers are commonly deployed. The presence of dangling pointers violates fundamental principles of safe resource lifecycle management, undermining trust in the kernel's ability to isolate faults within individual driver modules. System administrators may experience unpredictable behavior including random crashes during device enumeration or hotplug events, complicating troubleshooting efforts as standard logging mechanisms might not capture the precise moment of memory corruption due to asynchronous nature of some I/O operations.
To mitigate this vulnerability, developers must ensure strict symmetry between resource acquisition and release sequences within driver probe functions. The fix involves introducing a dedicated error handling label that explicitly calls iio_device_unregister before proceeding to buffer cleanup routines. This approach mirrors the teardown logic already implemented in the remove function for lidar devices, ensuring that all registered subsystems are properly deregistered prior to freeing associated memory structures. By aligning the failure path with successful initialization steps, the kernel prevents the creation of stale references and maintains integrity across the Industrial I/O framework.
From a broader security perspective, this incident highlights the importance of adhering to established coding standards for Linux kernel development that emphasize balanced resource management. It also underscores the need for rigorous static analysis tools capable of detecting mismatched register-unregister pairs in complex initialization sequences. Security teams should prioritize patching affected kernels and verify that deployment pipelines enforce these updates promptly. Additionally, implementing runtime checks or assertions during device teardown can help catch such discrepancies earlier in development cycles rather than relying solely on post-deployment vulnerability discovery mechanisms aligned with ATT&CK techniques related to privilege escalation through kernel exploitation vectors.