CVE-2026-98665 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: health: max30102: fix NULL dereference in interrupt handler
The interrupt is requested in max30102_probe() and stays enabled for the lifetime of the device, but indio_dev->active_scan_mask is only valid while a buffer is enabled. When an interrupt arrives while no buffer is enabled, the handler dereferences the NULL active_scan_mask:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __bitmap_weight+0x64/0x98 (P) max30102_interrupt_handler+0x48/0x160 [max30102]
Call max30102_fifo_count() at the top of the handler and return early unless it reports a FIFO sample is ready. Because FIFO_RDY is the only interrupt source enabled in max30102_chip_init(), an invocation of max30102_interrupt_handler() without the FIFO_RDY interrupt status bit set carries no data to read and can return before touching active_scan_mask. A negative return from max30102_fifo_count() indicates a failed interrupt status read and is treated the same way.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel driver for the MAX30102 health sensor, part of the Industrial I/O subsystem, contained a critical null pointer dereference vulnerability within its interrupt handling routine. This flaw stems from an architectural mismatch between the lifecycle management of hardware interrupts and software buffer states. Specifically, the device's interrupt line is requested during the probe phase and remains enabled for the entire lifetime of the device instance to ensure timely data acquisition. However, the driver relies on a pointer named active_scan_mask which is only allocated and valid when a user-space application has explicitly opened and activated an IIO buffer. This creates a race condition window where hardware interrupts can trigger while no buffer is active, leading to invalid memory access.
The technical root cause lies in the execution flow of the max30102_interrupt_handler function. When an interrupt occurs, the handler attempts to process data by referencing indio_dev->active_scan_mask without first verifying whether a buffer context exists or if there are actually samples available in the hardware FIFO register. If no buffer is enabled, this pointer remains NULL. Consequently, any subsequent operation that dereferences this pointer results in a kernel panic due to an attempt to access virtual address zero. The provided call trace confirms this behavior, showing the crash occurring within __bitmap_weight which is invoked by the interrupt handler before it can safely validate input data or buffer state.
From an operational impact perspective, this vulnerability allows for local denial of service against the host system. An attacker with physical access to the device or a user-space process capable of triggering specific hardware states could induce repeated interrupts without enabling the associated IIO buffer. Each such interrupt would crash the kernel, requiring a full system reboot and potentially causing data loss if critical processes were running at the time of the fault. While this is not directly exploitable for arbitrary code execution due to the nature of null pointer dereferences in modern kernels with KASLR and other mitigations, it severely impacts system availability and stability.
The resolution involves restructuring the interrupt handler logic to perform early validation checks before accessing sensitive driver structures. The fix introduces a call to max30102_fifo_count at the very beginning of the interrupt service routine. This function queries the hardware FIFO status register to determine if valid data samples are actually present. If no sample is ready, or if reading the status fails (indicated by a negative return value), the handler returns immediately without proceeding further. Since only the FIFO_RDY interrupt source is enabled during chip initialization, this check effectively filters out spurious interrupts that occur when no buffer is active and no data has been generated by the sensor.
This vulnerability aligns with CWE-476 which describes a NULL pointer dereference error where software incorrectly assumes a non-null value will always be provided. In terms of MITRE ATT&CK, this falls under T1053 Scheduled Task/Job as it involves system-level stability disruption through interrupt handling flaws, though more accurately classified under privilege escalation or denial of service vectors depending on the attacker's initial access level. The fix ensures that the driver adheres to safer coding practices by validating hardware state before accessing software-managed resources, thereby preventing kernel panics and maintaining system integrity during periods where no user-space application is consuming sensor data.