CVE-2026-98656: Linux Kernel Use-After-Free Vulnerability

CVE-2026-98656 Overview

CVE-2026-98656 is a use-after-free vulnerability in the Linux kernel's Industrial I/O (IIO) subsystem. The flaw resides in the trigger release path, where iio_trigger_notify_done_atomic() defers the ->reenable() callback into trig->reenable_work on the system workqueue. The worker dereferences the owning trigger through container_of(). Because nothing cancels this pending work before iio_trig_release() frees the trigger, a worker armed by the last in-flight IRQ can run after the free and access released memory.

The issue was discovered through an in-house static analysis tool and resolved upstream by cancelling the work at the top of iio_trig_release().

Critical Impact
A race between the final trigger release and a pending reenable_work item can lead to kernel memory corruption through access to freed trigger memory.

Affected Products

Linux kernel (IIO subsystem, drivers/iio/industrial-io-trigger.c)
Multiple stable kernel branches as referenced by the upstream fix commits
Any distribution kernel that ships the IIO trigger core prior to the backported patch

Discovery Timeline

2026-10-18 - CVE-2026-98656 published to NVD
2026-10-21 - Last updated in NVD database

Technical Details for CVE-2026-98656

Vulnerability Analysis

The Linux kernel IIO subsystem supports hardware triggers that notify consumer drivers when new sample data is ready. When a trigger IRQ completes, iio_trigger_notify_done_atomic() schedules the trigger's ->reenable() callback asynchronously by queuing trig->reenable_work on the system workqueue.

The worker uses container_of() on the embedded work_struct to recover the parent struct iio_trigger and invoke the hardware-specific reenable routine. This dereference assumes the trigger object remains valid for the lifetime of the queued work item.

No synchronization existed between trigger teardown and this deferred work. When the device core performed the final put_device() and invoked iio_trig_release(), the function freed the trigger without draining any outstanding reenable_work. A worker scheduled by the last in-flight interrupt could therefore execute after the backing memory was released.

Root Cause

The root cause is a missing cancellation of trig->reenable_work before the trigger structure is freed. The release path did not call cancel_work_sync() to wait for the pending worker to complete, violating the lifetime invariant required by container_of()-based dereference inside the work handler.

Attack Vector

Triggering the race requires the ability to cause an IIO trigger to be destroyed while a reenable work item is still queued or executing. The condition is a kernel-local race that depends on timing between IRQ completion and device teardown. Successful exploitation results in access to freed slab memory, which can lead to kernel memory corruption or information disclosure depending on how the freed region is reused.

The vulnerability mechanism is described in prose because no verified public exploit code is available. Review the upstream fix commits linked below for the exact code paths involved.

Detection Methods for CVE-2026-98656

Indicators of Compromise

Kernel log entries containing KASAN use-after-free reports referencing iio_trig_release or reenable_work handlers
Unexpected kernel oops or panic traces originating in the IIO trigger subsystem shortly after device removal or driver unload
WARN_ON or slab debugging messages pointing to freed struct iio_trigger allocations

Detection Strategies

Enable CONFIG_KASAN on test and canary systems to surface use-after-free conditions in the IIO trigger path
Audit loaded kernel versions against the fixed commits to identify unpatched hosts running IIO drivers
Monitor dmesg for stack traces referencing industrial-io-trigger.c functions during device hot-unplug or module unload events

Monitoring Recommendations

Collect kernel crash dumps centrally and alert on panics mentioning iio_trigger symbols
Track module load and unload events for IIO consumer drivers on sensor-equipped hosts
Correlate hardware IRQ storms on IIO devices with subsequent kernel instability

How to Mitigate CVE-2026-98656

Immediate Actions Required

Apply the upstream kernel patches referenced in the Patch Information section as soon as vendor builds become available
Inventory systems that load IIO trigger drivers, including industrial sensor platforms, embedded devices, and some laptops with accelerometer and ambient light sensors
Restrict physical and administrative access to systems that cannot be patched immediately, since the race requires device teardown events

Patch Information

The fix cancels reenable_work at the top of iio_trig_release(), which every free path reaches through the device core's final put_device(). Review and backport the upstream commits: Kernel Commit 2a57b92, Kernel Commit 882d001, Kernel Commit ac5d26a, Kernel Commit cf513df, and Kernel Commit e647032.

Workarounds

Unload IIO consumer drivers that are not required on production systems to eliminate the vulnerable code path
Avoid hot-unplug or rapid driver unload sequences on IIO-enabled hardware until patches are deployed
Where feasible, disable CONFIG_IIO in custom kernel builds for workloads that do not require industrial sensor support

bash

# Verify whether the IIO trigger module is loaded
lsmod | grep industrialio

# Check running kernel version against distribution advisories
uname -r