Re: [PATCH v3] iio: health: max30102: fix NULL dereference in interrupt handler

[Andy Shevchenko]

On Wed, Aug 5, 2026 at 7:06 AM Marco Chen <marcochen.dev@xxxxxxxxx> wrote:
>
> 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

>   pc : __bitmap_weight+0x64/0x98
>   lr : max30102_interrupt_handler+0x48/0x160 [max30102]

For these two lines see the below comment

>   Call trace:
>    __bitmap_weight+0x64/0x98 (P)
>    max30102_interrupt_handler+0x48/0x160 [max30102]

>    irq_thread_fn+0x28/0xa8
>    irq_thread+0x184/0x30c
>    kthread+0x118/0x124
>    ret_from_fork+0x10/0x20

As Submitting Patches documentation recommends these lines are not
significant in a traceback example and may be dropped. So altogether
drop 6 unneeded lines.

> 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.

-- 
With Best Regards,
Andy Shevchenko