Answer in brief
CVE-2026-89938 records a High severity (CVSS 7.8) vulnerability in iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=7103b99b031cb0ff6979331757bfc4893f37ae9e <f64b437641b5a70c18bb0fd38da2b69d8926c871 || >=7103b99b031cb0ff6979331757bfc4893f37ae9e <91e12b0fbd7047d02bf4ef4dbc491b9ef0159250 || >=7103b99b031cb0ff6979331757bfc4893f37ae9e <2071624c3d0f497ca91da78858e6f30d7112fea6 || >=7103b99b031cb0ff6979331757bfc4893f37ae9e <30b0d44c978bbc857bd68b71dab371805653de70 || >=7103b99b031cb0ff6979331757bfc4893f37ae9e <be61c8c6252671ecf1fee0ad90f87669e0be1e20 | f64b437641b5a70c18bb0fd38da2b69d8926c871, 91e12b0fbd7047d02bf4ef4dbc491b9ef0159250, 2071624c3d0f497ca91da78858e6f30d7112fea6, 30b0d44c978bbc857bd68b71dab371805653de70, be61c8c6252671ecf1fee0ad90f87669e0be1e20 |
| Linux/Linuxgeneric | 4.8 | Not reported |
Published upstream
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 16, 2026
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.
Quoted source text, attributed separately from HOL analysis.