CVE-2026-98657: iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure
iio: proximity: pulsedlight: fix iiodevice left registered on PM setup failure
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Compensating control
In the pulsedlight driver's probe() error path, add an error_unreg_dev label that calls iio_device_unregister() before falling through to the existing iio_triggered_buffer_cleanup(), mirroring the teardown order in lidar_remove().
Event History
Frequently Asked Questions
Under what condition can this issue occur?
It occurs when the driver probe has successfully registered the IIO device but pm_runtime_set_active() subsequently fails. The failed probe then frees the devm-managed device while its IIO registration remains active.
What is exposed if the failure occurs?
The registered sysfs and character-device nodes can remain live while pointing to freed memory. This leaves stale IIO interfaces after the driver probe returns an error.
How can the affected state be identified?
Look for a failed probe caused by pm_runtime_set_active() together with IIO sysfs or character-device nodes that remain present for the device. The condition is specifically an IIO device registration that was not undone during that probe failure.
What is the remediation?
Apply the fix that unregisters the IIO device on the PM setup error path before performing triggered-buffer cleanup. The corrected teardown order mirrors the existing lidar_remove() cleanup sequence.