CVE-2026-89938: iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF
In the Linux kernel, the following vulnerability has been resolved:
iio: chemical: atlas-sensor: use iiotriggerpollnested() to fix remove UAF
The atlas driver requests its hardware data-ready IRQ with devmrequestthreadedirq(); its threaded handler queues an irqwork, atlasworkhandler(), that calls iiotriggerpoll(data->trig).
The IRQ is devm-managed, so freeirq() runs from the devres unwind after atlasremove() returns without flushing that irqwork. Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irqwork can therefore run after the unwind has freed atlasdata/indiodev and the trigger, when atlasworkhandler() derives the atlasdata pointer via containerof() and dereferences data->trig, a use-after-free.
Call iiotriggerpollnested() directly from the threaded handler instead of bouncing through irqwork. freeirq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270).
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify the atlas driver so the threaded handler calls iio_trigger_poll_nested() rather than iio_trigger_poll() (fixes remove UAF where irq_work can run after unwind frees atlas_data/indio_dev).
Linux kernel iio chemical atlas-sensor driver Call iio_trigger_poll_nested() from threaded handler (instead of iio_trigger_poll()) = enabled
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.