iio: health: max30102: fix NULL dereference in interrupt handler
PATCH v3 1/1 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 pc : __bitmap_weight+0x64/0x98 lr : max30102_interrupt_handler+0x48/0x160 [max30102] 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
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.
---
Changes in v3:
- Reuse max30102_fifo_count() for the early return instead of reading the status register directly, as suggested by Jonathan.
- Return IRQ_HANDLED on cnt <= 0 rather than cnt == 0 so that a failed status read also returns early.
max30102_fifo_count() still has the odd name and int return you mentioned in v2, so I will send a follow-up patch once this lands.
Tested on a MAX30102 on Raspberry Pi 4 over I2C.
v1: https://lore.kernel.org/linux-iio/[email protected]/
v2: https://lore.kernel.org/linux-iio/[email protected]/
drivers/iio/health/max30102.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/iio/health/max30102.c +9 -3
@@ -290,9 +290,15 @@ static irqreturn_t max30102_interrupt_handler(int irq, void *private) {struct iio_dev *indio_dev = private;struct max30102_data *data =iio_priv (indio_dev); -unsigned int measurements =bitmap_weight (indio_dev->active_scan_mask, -iio_get_masklength (indio_dev)); -int ret, cnt =0 ; +unsigned int measurements; +int ret, cnt; + + cnt =max30102_fifo_count (data); +if (cnt <=0 ) +return IRQ_HANDLED ; + + measurements =bitmap_weight (indio_dev->active_scan_mask, +iio_get_masklength (indio_dev));mutex_lock (&data->lock);
Signature · 1 line
2.55.0
Quoted 11 lines · Marco Chen
The interrupt is requested in
max30102_probe()and stays enabled for the lifetime of the device, butindio_dev->active_scan_maskis only valid while a buffer is enabled. When an interrupt arrives while no buffer is enabled, the handler dereferences the NULLactive_scan_mask:Unable to handle kernel NULL pointer dereference at virtual address0000000000000000
pc : __bitmap_weight+0x64/0x98 lr : max30102_interrupt_handler+0x48/0x160 [max30102]
For these two lines see the below comment
Quoted 8 lines
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.
Quoted 7 lines
Call
max30102_fifo_count()at the top of the handler and return early unless it reports a FIFO sample is ready. BecauseFIFO_RDYis the only interrupt source enabled inmax30102_chip_init(), an invocation ofmax30102_interrupt_handler()without theFIFO_RDYinterrupt status bit set carries no data to read and can return before touchingactive_scan_mask. A negative return frommax30102_fifo_count()indicates a failed interrupt status read and is treated the same way.
Signature · 2 lines
With Best Regards, Andy Shevchenko