In the Linux kernel, the following vulnerability has been resolved:
iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF
The atlas driver requests its hardware data-ready IRQ with
devm_request_threaded_irq(); its threaded handler queues an irq_work,
atlas_work_handler(), that calls iio_trigger_poll(data->trig).
The IRQ is devm-managed, so free_irq() runs from the devres unwind after
atlas_remove() returns without flushing that irq_work. Once a buffer is
enabled, conversion-complete IRQs keep firing and queueing it; a pending
irq_work can therefore run after the unwind has freed atlas_data/indio_dev
and the trigger, when atlas_work_handler() derives the atlas_data pointer
via container_of() and dereferences data->trig, a use-after-free.
Call iio_trigger_poll_nested() directly from the threaded handler instead
of bouncing through irq_work. free_irq() 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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The use-after-free is reached from local IIO sysfs/chardev buffer enable on the Atlas I2C chemical sensor plus driver teardown (sysfs unbind, rmmod, or parent adapter removal). There is no network, Bluetooth, or remote-protocol path into atlas_interrupt_handler or atlas_work_handler.
AC:L - With the IIO buffer enabled, conversion-complete IRQs keep queueing irq_work every 450-650ms. atlas_remove() never calls irq_work_sync(), so pending work runs after the synchronous devres unwind frees atlas_data. The attacker controls buffer enable and bind/unbind retries; on PREEMPT_RT or CPUs without an irq_work IPI the window is milliseconds.
PR:L - IIO buffer/enable is mode 0644 with no capability check, and on industrial/IoT water-quality systems that ship Atlas OEM SM sensors those nodes are commonly group-accessible to monitoring services. Per driver-removal UAF scoring, an unprivileged local user can drive the IRQ/irq_work side while teardown proceeds; init-namespace root is not required.
UI:N - The attacker enables the IIO buffer themselves and coordinates driver unbind or module teardown; no separate victim action such as plugging hardware or mounting a filesystem is required.
S:U - The use-after-free corrupts kernel heap objects (atlas_data and the IIO trigger) in the host kernel's own security authority. This is a standard local kernel privilege-escalation path, not a VM, IOMMU, or sandbox boundary crossing.
C:H - atlas_work_handler() recovers freed atlas_data via container_of() and dereferences data->trig. A use-after-free of that sprayable driver-private object yields an arbitrary kernel read primitive, including via iio_trigger_poll() walking attacker-controlled trigger state.
I:H - After spraying the freed atlas_data, data->trig is attacker-controlled, so iio_trigger_poll() performs atomic updates and generic_handle_irq() on attacker-chosen IRQ numbers. That is an arbitrary kernel write and control-flow hijack primitive, consistent with use-after-free scoring.
A:H - The pending irq_work running against freed atlas_data and the IIO trigger causes a kernel oops or panic (KASAN use-after-free or a wild dereference of data->trig), so availability impact is high even without a full exploit.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The use-after-free is reached from local IIO sysfs/chardev buffer enable on the Atlas I2C chemical sensor plus driver teardown (sysfs unbind, rmmod, or parent adapter removal). There is no network, Bluetooth, or remote-protocol path into atlas_interrupt_handler or atlas_work_handler.
AC:L - With the IIO buffer enabled, conversion-complete IRQs keep queueing irq_work every 450-650ms. atlas_remove() never calls irq_work_sync(), so pending work runs after the synchronous devres unwind frees atlas_data. The attacker controls buffer enable and bind/unbind retries; on PREEMPT_RT or CPUs without an irq_work IPI the window is milliseconds.
PR:L - IIO buffer/enable is mode 0644 with no capability check, and on industrial/IoT water-quality systems that ship Atlas OEM SM sensors those nodes are commonly group-accessible to monitoring services. Per driver-removal UAF scoring, an unprivileged local user can drive the IRQ/irq_work side while teardown proceeds; init-namespace root is not required.
UI:N - The attacker enables the IIO buffer themselves and coordinates driver unbind or module teardown; no separate victim action such as plugging hardware or mounting a filesystem is required.
S:U - The use-after-free corrupts kernel heap objects (atlas_data and the IIO trigger) in the host kernel's own security authority. This is a standard local kernel privilege-escalation path, not a VM, IOMMU, or sandbox boundary crossing.
C:H - atlas_work_handler() recovers freed atlas_data via container_of() and dereferences data->trig. A use-after-free of that sprayable driver-private object yields an arbitrary kernel read primitive, including via iio_trigger_poll() walking attacker-controlled trigger state.
I:H - After spraying the freed atlas_data, data->trig is attacker-controlled, so iio_trigger_poll() performs atomic updates and generic_handle_irq() on attacker-chosen IRQ numbers. That is an arbitrary kernel write and control-flow hijack primitive, consistent with use-after-free scoring.
A:H - The pending irq_work running against freed atlas_data and the IIO trigger causes a kernel oops or panic (KASAN use-after-free or a wild dereference of data->trig), so availability impact is high even without a full exploit.
CVSS 3.1