linux-kernel - Re: [PATCH] iio: accel: bmc150: Do not configure IRQ registers if no IRQ connected

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8f7656ed-0a28-4ba0-accc-b19817bbb38b@baylibre.com>
Date: Fri, 13 Jun 2025 10:03:34 -0500
From: David Lechner <dlechner@...libre.com>
To: Marek Vasut <marek.vasut+bmc150@...lbox.org>, linux-iio@...r.kernel.org
Cc: Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, Jonathan Cameron <jic23@...nel.org>,
 Julien Stephan <jstephan@...libre.com>, Peter Zijlstra
 <peterz@...radead.org>, Salvatore Bonaccorso <carnil@...ian.org>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: accel: bmc150: Do not configure IRQ registers if no
 IRQ connected

On 6/13/25 7:45 AM, Marek Vasut wrote:
> The BMC150 on Onemix 2S does not have IRQ line described in ACPI tables,
> which leads to bmc150_accel_core_probe() being called with irq=0, which
> leads to bmc150_accel_interrupts_setup() never being called, which leads
> to struct bmc150_accel_data *data ->interrupts[i].info being left unset
> to NULL. Later, userspace can indirectly trigger bmc150_accel_set_interrupt()
> which depends on struct bmc150_accel_data *data ->interrupts[i].info being
> non-NULL, and which triggers NULL pointer dereference. This is triggered
> e.g. from iio-sensor-proxy.

Is the interrupt not wired up or is it just missing from the table?

> 
> Fix this by skipping the IRQ register configuration in case there is no
> IRQ connected in hardware, in a manner similar to what the driver did in
> the very first commit which added the driver.
> 

...

> diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
> index 744a034bb8b5..1c3583ade2b4 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -550,6 +550,9 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
>  	if (ret < 0)
>  		return ret;
>  

A comment here explaining why this is needed and what the consequences
are would be helpful.

The obvious one to me is that we won't get events even when events are enabled.
It isn't so clear to me though what happens if the watermark interrupt isn't
enabled during buffered reads.

> +	if (!info)
> +		return 0;
> +
>  	/* map the interrupt to the appropriate pins */
>  	ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
>  				 (state ? info->map_bitmask : 0));