CVE-2026-89938: iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF
iio: chemical: atlas-sensor: use iiotriggerpollnested() to fix remove UAF
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.157.1-1 - 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 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In the atlas-sensor threaded IRQ handler, call iio_trigger_poll_nested() directly instead of queuing irq_work and calling iio_trigger_poll() from atlas_work_handler().
Event History
Frequently Asked Questions
Which deployments are exposed to the use-after-free condition?
Systems using the Linux kernel atlas-sensor IIO driver are exposed when an IIO buffer is enabled. In that state, conversion-complete interrupts can continue to queue work while the driver is being removed.
What timing is required for the issue to occur?
A conversion-complete IRQ must queue the driver's irq_work before or during device removal, and that work must execute after devres cleanup has freed the driver data, IIO device, and trigger. The queued work then dereferences the freed trigger through the atlas_data structure.
How can maintainers recognize the vulnerable implementation?
The vulnerable path uses a threaded data-ready IRQ handler that queues irq_work, whose handler calls iio_trigger_poll(data->trig). The corrected approach calls iio_trigger_poll_nested() directly from the threaded IRQ handler, allowing free_irq() to drain that handler during cleanup.