Re: [PATCH v3] iio: health: max30102: fix NULL dereference in interrupt handler
Andy Shevchenko <[email protected]>
| Newsgroups | dev.linux.lists.linux-kernel-mentees,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAHp75VdL+NarOfkY7mOB1U3Aud-TMjM8MPEsCapjYCoL0ikpbg@mail.gmail.com> |
On Wed, Aug 5, 2026 at 7:06 AM Marco Chen <[email protected]> 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