CVE-2026-98665: Linux Kernel max30102 Use-After-Free Vulnerability

CVE-2026-98665 Overview

CVE-2026-98665 is a NULL pointer dereference in the Linux kernel's Industrial I/O (IIO) subsystem, specifically in the max30102 health sensor driver. The interrupt handler dereferences indio_dev->active_scan_mask without validating that a buffer is enabled. The interrupt is requested in max30102_probe() and remains enabled for the lifetime of the device, but active_scan_mask is only valid while a buffer is active. An interrupt arriving outside of an active buffer session triggers a kernel NULL pointer dereference inside __bitmap_weight(), resulting in a kernel oops.

Critical Impact
A spurious or legitimate interrupt from the MAX30102 sensor while no IIO buffer is enabled causes a kernel NULL pointer dereference, leading to a denial of service on affected Linux systems.

Affected Products

Linux kernel builds that include the max30102 IIO health sensor driver (drivers/iio/health/max30102.c)
Embedded and IoT Linux platforms using the Maxim MAX30102 pulse oximeter and heart-rate sensor
Stable kernel branches prior to the fixes referenced in commits 2a74f30, 6069910, 8d6f989, eeb23ba, and f0ea482

Discovery Timeline

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

Technical Details for CVE-2026-98665

Vulnerability Analysis

The max30102 driver supports the Maxim MAX30102 pulse oximeter sensor through the Linux IIO framework. During probe, the driver registers an interrupt handler that remains enabled for the device lifetime. The handler reads samples from the sensor FIFO and distributes them to IIO buffer consumers by consulting indio_dev->active_scan_mask.

The active_scan_mask field is only initialized while an IIO buffer is enabled by userspace. When the interrupt fires outside of that window, the handler calls __bitmap_weight() on a NULL pointer, producing the kernel oops shown in the upstream commit message:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Call trace:
 __bitmap_weight+0x64/0x98 (P)
 max30102_interrupt_handler+0x48/0x160 [max30102]

This is a classic ordering issue between interrupt lifetime and buffer lifetime in IIO drivers [CWE-476].

Root Cause

The driver assumes the interrupt handler only runs while a consumer has enabled an IIO buffer. That assumption is incorrect because the IRQ is requested at probe time and stays unmasked. Any FIFO-ready assertion, or a stray interrupt, invokes the handler and dereferences an uninitialized active_scan_mask pointer.

Attack Vector

Exploitation requires an interrupt from the MAX30102 sensor while no IIO buffer is enabled. A local user with the ability to toggle IIO buffer state, or physical conditions that cause the sensor to assert its interrupt line, can trigger the fault. The resulting NULL pointer dereference generates a kernel oops and renders the affected task or system unusable, producing a denial-of-service condition. No remote attack vector is documented.

The upstream fix calls max30102_fifo_count() at the top of the handler and returns early unless the FIFO_RDY status bit is set. Because FIFO_RDY is the only interrupt source enabled in max30102_chip_init(), the handler now exits cleanly before touching active_scan_mask. A negative return from max30102_fifo_count(), indicating a failed status read, is treated the same way.

Detection Methods for CVE-2026-98665

Indicators of Compromise

Kernel oops entries referencing max30102_interrupt_handler and __bitmap_weight in dmesg or /var/log/kern.log
Unexpected process crashes or system reboots on devices that integrate the MAX30102 sensor
Repeated interrupt-driven faults correlated with userspace opening or closing IIO buffers under /sys/bus/iio/devices/

Detection Strategies

Audit running kernel versions against the fixed commits (2a74f30, 6069910, 8d6f989, eeb23ba, f0ea482) across the fleet
Monitor kernel ring buffer messages for NULL pointer dereference events whose call stack includes IIO health drivers
Inventory Linux-based IoT and medical wearables that load the max30102 module and flag those still on unpatched kernels

Monitoring Recommendations

Forward dmesg and journald kernel streams to a centralized logging platform for oops pattern detection
Alert on repeated kernel panics from the same driver module to surface stability or exploitation attempts
Track IIO buffer enable and disable transitions on affected devices to correlate crashes with buffer state

How to Mitigate CVE-2026-98665

Immediate Actions Required

Apply the upstream Linux stable kernel updates that include commits 2a74f30a7bb3, 60699102827f, 8d6f98972fe2, eeb23ba97bd8, and f0ea4824deeb
Rebuild and redeploy custom kernel images for embedded devices that ship the max30102 driver
Prioritize patching for devices where userspace or physical actors can toggle sensor interrupts

Patch Information

The fix is distributed across the Linux stable tree. See the upstream commits for the exact code change: Kernel Git Commit 2a74f30, Kernel Git Commit 6069910, Kernel Git Commit 8d6f989, Kernel Git Commit eeb23ba, and Kernel Git Commit f0ea482. The patch adds an early FIFO status check in max30102_interrupt_handler() so the handler returns before dereferencing active_scan_mask.

Workarounds

Unload the max30102 kernel module on systems that do not require pulse oximeter functionality using modprobe -r max30102
Blacklist the driver through /etc/modprobe.d/ on devices where the sensor is not actively used
Keep IIO buffers continuously enabled on affected devices until the patched kernel is deployed, so active_scan_mask remains valid

bash

# Blacklist the vulnerable driver until a patched kernel is deployed
echo "blacklist max30102" | sudo tee /etc/modprobe.d/blacklist-max30102.conf
sudo modprobe -r max30102