CVE-2026-98662 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: light: gp2ap020a00f: drain irq_work after free_irq
The threaded IRQ handler queues data->work through irq_work_queue() so the trigger is polled from a per-CPU context. free_irq() does not flush an irq_work the handler already queued, so after gp2ap020a00f_remove() returns that work may still run and call iio_trigger_poll() on data->trig, which the devm cleanup has already freed, causing a use-after-free.
Add irq_work_sync(&data->work) after free_irq() in remove() and in the probe error path, mirroring commit 78601726d4a5 ("iio: trigger: sysfs: fix use-after-free on remove").
Found by an in-house static analysis tool, confirmed by manual review.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified within the Linux kernel's Industrial I/O subsystem specifically affects the gp2ap020a00f light sensor driver. This issue manifests as a classic use-after-free condition arising from improper synchronization during device removal or probe failure scenarios. The core of the problem lies in the interaction between asynchronous interrupt handling mechanisms and resource deallocation routines. When the threaded IRQ handler for this specific hardware component is active, it utilizes irq_work_queue to schedule data processing tasks that are executed within a per-CPU context. This design allows for efficient polling and data retrieval without blocking the primary interrupt line, but it introduces complexity regarding lifecycle management when the device driver is being unloaded or fails to initialize correctly.
The technical flaw occurs because the standard free_irq function, which releases the requested interrupt line associated with the device, does not automatically flush or wait for any irq_work items that have already been queued by the handler. Consequently, if a work item has been scheduled but not yet executed at the moment free_irq is called, there remains a window of opportunity where that pending work can execute after the driver's removal function has returned and the device-managed resources have been cleaned up. Specifically, the iio_trigger_poll function may be invoked on data->trig, which refers to an IIO trigger structure that was previously freed by devm cleanup routines. Accessing this memory region constitutes a use-after-free vulnerability, leading to potential kernel crashes, data corruption, or arbitrary code execution if the freed memory has been reallocated for malicious purposes.
From a security and stability perspective, this flaw represents a significant risk in environments where hardware drivers are frequently loaded and unloaded, such as in containerized systems or dynamic device management scenarios. The exploitation of this vulnerability could allow an attacker with local access to destabilize the kernel by triggering the execution of code on freed memory structures. This aligns closely with CWE-416, which describes use-after-free errors where a pointer is used after it has been freed, often leading to undefined behavior and security breaches. Furthermore, in terms of attack vectors, this scenario can be mapped to ATT&CK technique T1059, specifically command execution through kernel exploitation, although the primary impact here is system stability rather than direct privilege escalation without further chaining with other vulnerabilities.
The resolution involves ensuring that all pending irq_work items are synchronized and completed before the interrupt line is released. This is achieved by inserting an irq_work_sync call immediately after free_irq in both the remove function and the probe error path. This synchronization step guarantees that any work scheduled prior to the release of the IRQ will be executed within a safe context where the necessary data structures remain valid, or ensures they are properly handled before resources are reclaimed. This approach mirrors fixes applied to other parts of the IIO subsystem, such as the sysfs trigger driver, establishing a consistent pattern for handling asynchronous work in device lifecycle management.
To mitigate this vulnerability and similar issues in kernel development, it is essential to rigorously audit all instances where async work items interact with resources that are subject to early deallocation during error paths or removal sequences. Developers should always verify whether the underlying framework functions handle pending asynchronous tasks automatically; if not, explicit synchronization calls like irq_work_sync must be employed. Static analysis tools play a crucial role in identifying these race conditions and lifecycle mismatches before they reach production kernels. Additionally, adhering to established kernel coding standards that emphasize careful ordering of resource release operations can prevent such logical errors from occurring. Regular updates to the Linux kernel are recommended for users relying on affected versions to ensure this synchronization logic is present and functioning correctly.