Cloudanix VulnDB

CVE-2026-98662

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel handles a light sensor can let code keep running after part of the driver has been cleaned up, which may crash the system or allow an attacker with local access to take control.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the gp2ap020a00f IIO light sensor driver: free_irq() leaves a pending irq_work that may later invoke iio_trigger_poll on a devm-freed trigger after module removal or probe failure.

Why it matters to the business

On systems with the affected sensor, device unload or driver error paths can trigger kernel instability, crashes, or local privilege escalation; low prevalence reduces widespread risk but requires attention on embedded or sensor-equipped Linux deployments.

How an attack unfolds

An attacker with local access loads or unloads the gp2ap020a00f module (or triggers probe failure) while irq_work is queued; the unsynced work then dereferences the already-freed trigger object, enabling use-after-free exploitation.

How to fix it

Apply the upstream fix by adding irq_work_sync(&data->work) after free_irq in both remove() and probe error paths; rebuild and deploy a patched kernel. Monitor for backports in distribution kernels.

How to confirm the fix worked

Inspect the driver source for irq_work_sync calls immediately after free_irq in gp2ap020a00f_remove and the probe error path; confirm via kernel build logs or runtime module reload tests that no pending work dereferences freed objects.

Typical attack path

  1. Obtain local code execution or physical access to trigger module removal
  2. Cause gp2ap020a00f_remove or probe error path to execute while irq_work is pending
  3. Allow the irq_work callback to run after devm cleanup and dereference the freed iio_trigger
  4. Leverage resulting UAF for kernel memory corruption or code execution

How to detect it

Monitor kernel logs for use-after-free reports, oops, or warnings referencing gp2ap020a00f, irq_work, or iio_trigger_poll during module removal; correlate with device unplug or driver unload events.

What your security team should do

  • Identify systems exposing the gp2ap020a00f sensor and schedule kernel updates
  • Prioritize patching on devices where module load/unload occurs frequently
  • Add kernel UAF monitoring for iio_trigger_poll symbols until patches are deployed

The record

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.

Affected packages

Ecosystem Package Introduced Fixed