CVE-2026-98665
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A flaw in the Linux kernel code handling a particular health sensor can crash the entire system if the sensor signals an interrupt at the wrong time.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
NULL pointer dereference in max30102_interrupt_handler when active_scan_mask is accessed outside of an enabled IIO buffer, triggered by an interrupt with no FIFO data ready.
Why it matters to the business
Kernel panic or denial of service on Linux systems using the MAX30102 sensor, potentially disrupting operations on embedded or IoT devices; low exploitation likelihood reduces urgency but still requires patching within normal maintenance windows.
How an attack unfolds
An attacker with local access or the ability to trigger sensor interrupts (for example via hardware manipulation or concurrent IIO buffer operations) causes the handler to execute without an active buffer, leading to the NULL dereference and system crash.
How to fix it
Apply the upstream fix that calls max30102_fifo_count at the start of the handler and returns early unless a FIFO sample is ready; rebuild and deploy the updated kernel module or full kernel image.
How to confirm the fix worked
Confirm the patched handler logic is present by inspecting the max30102 driver source or module; reproduce interrupt scenarios with and without an active buffer to verify no dereference occurs.
Typical attack path
- Obtain local access or hardware proximity to the affected device
- Ensure or force a condition where the max30102 interrupt fires while no IIO buffer is enabled
- Trigger the interrupt handler path that dereferences active_scan_mask
- Cause kernel NULL pointer dereference resulting in panic or DoS
How to detect it
Search kernel logs and crash dumps for the call trace containing max30102_interrupt_handler and __bitmap_weight; look for oops messages referencing NULL pointer dereference at address 0 in the context of the max30102 module.
- max30102_interrupt_handler+0x48/0x160
- __bitmap_weight+0x64/0x98
- Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
What your security team should do
- Prioritize patching Linux kernels containing the max30102 driver in the next scheduled update cycle
- Review device configurations to determine if the MAX30102 is in use and consider disabling the driver if the sensor is not required
- Monitor kernel logs for NULL dereference oops matching the described call trace
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|