CVE-2026-98656 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: trigger: cancel reenable_work before freeing trigger
iio_trigger_notify_done_atomic() defers ->reenable() into trig->reenable_work on the system workqueue, and the worker dereferences the owning trigger through container_of(). Nothing cancels this work before iio_trig_release() frees the trigger, so a worker armed by the last in-flight IRQ can outlive the free and touch freed memory.
Cancel it at the top of iio_trig_release(), which every free path reaches through the device core's final put_device().
Found by an in-house static analysis tool.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The identified vulnerability resides within the Industrial I/O (IIO) subsystem of the Linux kernel, specifically affecting the trigger management infrastructure. This issue represents a classic use-after-free condition arising from improper synchronization between asynchronous work items and resource deallocation paths. The core mechanism involves the function iio_trigger_notify_done_atomic(), which is responsible for handling notifications related to trigger states. When this function determines that a re-enable operation must be deferred, it schedules a worker item named reenable_work onto the system-wide workqueue. This design choice allows non-blocking execution of potentially sleepable operations in process context, but it introduces complexity regarding lifecycle management because the scheduled worker retains a reference to its parent trigger structure via container_of macro dereferences.
The critical flaw lies in the timing and sequence of resource cleanup during the release phase of an IIO trigger device. The function iio_trig_release() serves as the central point for freeing all resources associated with a specific trigger, including memory allocated for the trigger structure itself. However, prior to this vulnerability fix, there was no mechanism to cancel or flush any pending reenable_work items before the actual memory deallocation occurred. Consequently, if an interrupt request (IRQ) arrives just before or during the release process, it may queue another instance of the re-enable work item onto the system workqueue. Because the kernel's workqueue subsystem does not automatically invalidate pointers when the underlying data structures are freed, this queued worker continues to exist in memory as a pending task.
When the scheduler eventually executes this deferred worker after iio_trig_release() has completed and returned control to the device core, the worker attempts to access the trigger structure through its stored pointer. Since that memory has already been released back to the kernel allocator pool, it may have been reallocated for other purposes or marked as free but not yet zeroed out depending on allocation flags. Accessing this invalid memory address constitutes a use-after-free vulnerability. This can lead to severe operational impacts including kernel panics due to page faults when accessing unmapped or protected pages, data corruption if the freed memory was reused by another subsystem and contains sensitive information, or potential privilege escalation exploits where an attacker crafts specific timing conditions to manipulate control flow through corrupted pointers within the trigger structure.
From a vulnerability classification perspective, this issue aligns with CWE-416: Use After Free, which describes situations where software continues to use memory after it has been freed. In terms of adversarial tactics, this could be leveraged in an ATT&CK context under techniques related to execution or defense evasion if exploited by local attackers seeking to crash the system for denial of service or escalate privileges via kernel exploitation chains. The root cause is fundamentally a race condition between asynchronous workqueue processing and synchronous resource deallocation, exacerbated by the lack of explicit cancellation logic during teardown sequences.
The resolution implemented in this patch addresses the issue by inserting a call to cancel_reenable_work at the very beginning of iio_trig_release(). This ensures that any pending or currently executing re-enable worker is stopped before the trigger structure memory is freed. By placing this check early in the release path, which is invoked through the device core's final put_device() mechanism for every free operation, the fix guarantees consistency across all code paths that lead to trigger destruction. This approach prevents the dangling pointer dereference by ensuring the work item no longer has a valid target before its memory becomes invalid.
Mitigation strategies beyond this patch include rigorous static analysis during development phases to detect similar lifecycle mismatches in other kernel subsystems using deferred execution models. Developers should ensure that any asynchronous task holding references to dynamically allocated structures explicitly cancels or flushes those tasks prior to freeing the referenced objects. Additionally, employing tools like KASAN (Kernel Address Sanitizer) can help identify such use-after-free bugs during testing by detecting invalid memory accesses in real-time. For system administrators running affected kernels, applying this patch is essential to maintain stability and security integrity of industrial control systems relying on IIO devices for sensor data acquisition.