CVE-2026-98656

What it actually does

Use-after-free in the Linux kernel IIO trigger subsystem where iio_trigger_notify_done_atomic() schedules ->reenable() work on the system workqueue that dereferences the trigger via container_of(), but iio_trig_release() frees the trigger without canceling the pending work, allowing the worker to touch freed memory.

Why it matters to the business

Linux systems processing IIO sensor triggers may experience kernel crashes, memory corruption, or potential privilege escalation, leading to system instability or compromise on affected devices and servers.

How an attack unfolds

An attacker with the ability to arm IIO triggers and deliver IRQs triggers the deferred reenable work, races the final trigger release through device put_device, and causes the out-of-lifetime worker to dereference freed memory for denial-of-service or arbitrary code execution.

How to fix it

Apply the upstream kernel patch that cancels reenable_work at the start of iio_trig_release(); rebuild and deploy a fixed kernel version containing this change.

How to confirm the fix worked

Confirm the presence of the cancel_work_sync call at the beginning of iio_trig_release() in the kernel source; test by exercising trigger arm/release paths under load and verifying absence of use-after-free reports in KASAN or similar sanitizers.

Typical attack path

1. Identify or create an IIO trigger device
2. Arm the trigger and generate a final IRQ to schedule reenable_work
3. Trigger trigger release via device removal or unregistration
4. Race the workqueue execution against the free in iio_trig_release
5. Use the resulting use-after-free for memory corruption or crash

How to detect it

Inspect kernel logs for oops/panic traces referencing iio_trig_release, container_of on a trigger, or workqueue execution after device release; look for KASAN or KMSAN reports mentioning freed trigger memory.

What your security team should do

• Prioritize kernel updates on systems exposing IIO triggers
• Monitor for kernel oops or panic logs involving iio_trig_release or reenable_work
• Limit unprivileged access to IIO devices where possible until patched