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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a771f5b8-aa24-b736-4e8f-b3b46a15dcb6@roeck-us.net>
Date:   Sat, 30 Jan 2021 07:31:48 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     "Matwey V. Kornilov" <matwey@....msu.ru>,
        Jean Delvare <jdelvare@...e.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        "open list:HARDWARE MONITORING" <linux-hwmon@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Cc:     matwey.kornilov@...il.com
Subject: Re: [PATCH] hwmon: lm75: Use zero lm75_type for lm75

On 1/30/21 2:10 AM, Matwey V. Kornilov wrote:
> There is a logical flaw in lm75_probe() function introduced in
> 
>     e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
> 
> Note, that of_device_get_match_data() returns NULL when no match
> found. This is the case when OF node exists but has unknown
> compatible line, while the module is still loaded via i2c
> detection.
> 
> arch/powerpc/boot/dts/fsl/p2041rdb.dts:
> 
>     lm75b@48 {
>     	compatible = "nxp,lm75a";
>     	reg = <0x48>;
>     };
> 
> In this case, the sensor is mistakenly considered as ADT75 variant.
> The simplest way to handle this issue is to make the LM75 code
> zero.
> 

This doesn't really solve the problem since it would match _all_
non-existing entries with lm75 (instead of whatever is intended).
That doesn't matter for lm75a, but it would matter if someone
would enter, say, "bla,adt75".

On a side note, "nxp,lm75a" (nor "nxp,lm75", for that matter) is not a
documented compatible string for this driver. If anything, we would
need a means to explicitly reject such undefined compatible strings.
One option might be to define the first entry in enum lm75_type
explicitly as invalid, check for it and reject it if returned.

Guenter

> Fixes: e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
> Signed-off-by: Matwey V. Kornilov <matwey@....msu.ru>
> ---
>  drivers/hwmon/lm75.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index e447febd121a..3aa7f9454f57 100644
> --- a/drivers/hwmon/lm75.c
> +++ b/drivers/hwmon/lm75.c
> @@ -25,12 +25,12 @@
>   */
>  
>  enum lm75_type {		/* keep sorted in alphabetical order */
> +	lm75 = 0,		/* except of lm75 which is default fallback */
>  	adt75,
>  	ds1775,
>  	ds75,
>  	ds7505,
>  	g751,
> -	lm75,
>  	lm75a,
>  	lm75b,
>  	max6625,
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ