linux-kernel - Re: [PATCH] leds: lm3697: Fix out-of-bound access

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]

Date:   Tue, 6 Oct 2020 16:41:01 +0200
From:   Marek Behun <kabel@...ckhole.sk>
To:     Dan Murphy <dmurphy@...com>
Cc:     <ultracoolguy@...anota.com>, Pavel <pavel@....cz>,
        Linux Leds <linux-leds@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH] leds: lm3697: Fix out-of-bound access

Adding Rob to Cc, Rob, could we have your opinion on this? Mine is below.

On Tue, 6 Oct 2020 07:21:14 -0500
Dan Murphy <dmurphy@...com> wrote:

> >> By the way I just realized that the DT binding in this driver seems
> >> incorrect to me.
> >>
> >> The controller logically supports 3 LED strings, each having
> >> configurable control bank.  
> 
> There are two control banks. You can connect the HVLED outputs to either 
> control bank A or B there is no individual control of the LED strings.
> 
> 
> >> But the DT binding supports 2 DT nodes, one for each control bank
> >> (identified by the `reg` property) and then `led-sources` says which
> >> string should be controlled by given bank.
> >>
> >> But taking in mind that DT should describe how devices are connected to
> >> each other, I think the child nodes in the binding should instead
> >> describe the 3 supported LED strings...  
> 
> The outputs in this case are virtual outputs which are the banks (A and B).
> 
> Since the device is bank controlled the actual current sinks are not 
> defined thus making the the banks the actual outputs.
> 
> This is why the 'reg' property defines the control bank either A or B 
> and the led-sources indicates the strings associated with the control bank.
> 
> Dan
> 

Dan, I looked at the datasheet, I understand this.

Nonetheless, device tree should describe how devices are connected to
each other. The chip has 3 pins for 3 LED strings.

If this controller should be able to support 3 LED strings via 3
outputs, the device tree binding nodes should, in my opinion, describe
each pin connected string. The nodes should maybe even be called
'led-string@N' where N is from [0, 1, 2].

The fact that the device is bank controlled and there are only two
banks (and it is configurable by which bank each LED string is
controlled) is more relevant to the driver, not as much to device tree
binding.

But yes, I do realize that if we had 3 child nodes, and the driver
created 3 LEDs, then changing brithrness on one of the 3 LEDs would
change brightness on at least another one, which we do not want.

Maybe this driver could parse these 3 `led-string` nodes, each having
defined bank via `led-sources`, and then register LED classdevs for
each bank that is mentioned. This way the device tree would be more
correct, IMO, and the driver would not have the problem mentioned in
the paragraph above.

Marek