LinuxLists.cc - [PATCH] leds: lm3697: Fix out-of-bound access

[permalink] [raw]

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

Hi!

> Signed-off-by: Ultracoolguy <[email protected]>

I'll need your real name to apply a patch.

> Hi, all. This is a patch fixing an out-of-bounds error due to lm3697_init expecting the device tree to use both control banks.? This fixes it by adding a new variable that will hold the number of used banks.
>
> Panic caused by this bug:

> <7>[??? 3.059893] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G??????? W???????? 5.9.0-rc7-postmarketos-qcom-msm8953 #71

Ok, so I assume this is only problem with certain device trees, and
not a problem with dts' in mainline?

This is not trivial patch, no need to cc trivial tree. OTOH Ccing
Marek who did a lot of cleanups in -next might be useful. Doing that
now.

Best regards,

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:

(No filename) (907.00 B)
signature.asc (201.00 B)
Download all attachments

2020-10-03 14:47:40

[permalink] [raw]

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

>I'll need your real name to apply a patch.

My real name is Gabriel David.

>Ok, so I assume this is only problem with certain device trees, and
not a problem with dts' in mainline?

Yes.
Here's the current node I'm using that causes this bug:

&i2c_5 {
        status = "ok";

        ti_lm3697@36 {
                        compatible = "ti,lm3697";
                        #address-cells = <1>;
                        #size-cells = <0>;
                        reg = <0x36>;

                        led@1 {
                                reg = <1>;
                                led-sources = <0 1 2>;
                                ti,brightness-resolution = <2047>;
                                label = "white:backlight";
                        };
        };
};

>This is not trivial patch, no need to cc trivial tree. OTOH Ccing
Marek who did a lot of cleanups in -next might be useful. Doing that
now.

Sorry for that. Gonna CC Marek from now on.

Btw thanks for the quick response!

Oct 3, 2020, 13:56 by [email protected]:

> Hi!
>
>> Signed-off-by: Ultracoolguy <[email protected]>
>>
>
> I'll need your real name to apply a patch.
>
>> Hi, all. This is a patch fixing an out-of-bounds error due to lm3697_init expecting the device tree to use both control banks. This fixes it by adding a new variable that will hold the number of used banks.
>>
>> Panic caused by this bug:
>>
>> <7>[    3.059893] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G        W         5.9.0-rc7-postmarketos-qcom-msm8953 #71
>>
>
> Ok, so I assume this is only problem with certain device trees, and
> not a problem with dts' in mainline?
>
> This is not trivial patch, no need to cc trivial tree. OTOH Ccing
> Marek who did a lot of cleanups in -next might be useful. Doing that
> now.
>
> Best regards,
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

2020-10-05 12:20:56

[permalink] [raw]

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

On Sat, 3 Oct 2020 15:02:51 +0200 (CEST)
[email protected] wrote:

> From 0dfd5ab647ccbc585c543d702b44d20f0e3fe436 Mon Sep 17 00:00:00 2001
> From: Ultracoolguy <[email protected]>
> Date: Fri, 2 Oct 2020 18:27:00 -0400
> Subject: [PATCH] leds:lm3697:Fix out-of-bound access
>
> If both led banks aren't used in device tree,
> an out-of-bounds condition in lm3697_init occurs
> because of the for loop assuming that all the banks are used.
> Fix it by adding a variable that contains the number of used banks.
>
> Signed-off-by: Ultracoolguy <[email protected]>
> ---
> drivers/leds/leds-lm3697.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/leds/leds-lm3697.c b/drivers/leds/leds-lm3697.c
> index 024983088d59..a4ec2b6077e6 100644
> --- a/drivers/leds/leds-lm3697.c
> +++ b/drivers/leds/leds-lm3697.c
> @@ -56,7 +56,7 @@ struct lm3697_led {
> struct ti_lmu_bank lmu_data;
> int control_bank;
> int enabled;
> - int num_leds;
> + int num_led_strings;

OK, I looked at the datasheet for this controlled. The controlled can
control 3 LED strings, each having several LEDs connected in series.
But only 2 different brightnesses can be set (control bank), so for each
string there is a register setting which control bank should control it.

The Control Bank is set via the `reg` DT property (reg=0 means
Control Bank A, reg=1 means Control Bank B). The `led-sources`
property defines which strings should be controlled by each bank.

So I think this variable name should stay num_leds (as in number of leds
in this control bank).
The structure though should be renamed:
struct lm3697_led -> struct lm3697_bank.

> };
>
> /**
> @@ -78,6 +78,7 @@ struct lm3697 {
> struct mutex lock;
>
> int bank_cfg;
> + int num_leds;

This should be named num_banks.

>
> struct lm3697_led leds[];

This variable should be named banks, i.e.:
struct lm3697_bank banks[];

> };
> @@ -180,7 +181,7 @@ static int lm3697_init(struct lm3697 *priv)
> if (ret)
> dev_err(&priv->client->dev, "Cannot write OUTPUT config\n");
>
> - for (i = 0; i < LM3697_MAX_CONTROL_BANKS; i++) {
> + for (i = 0; i < priv->num_leds; i++) {

Ultracoolguy is correct that this for cycle should not iterate
LM3697_MAX_CONTROL_BANKS. Instead, the count check in lm3697_probe should be changed from

if (!count)
to
if (!count || count > LM3697_MAX_CONTROL_BANKS)

(the error message should also be changed, or maybe dropped, and the
error code changed from -ENODEV to -EINVAL, if we use || operator).

> led = &priv->leds[i];
> ret = ti_lmu_common_set_ramp(&led->lmu_data);
> if (ret)
> @@ -244,22 +245,22 @@ static int lm3697_probe_dt(struct lm3697 *priv)
> led->lmu_data.lsb_brightness_reg = LM3697_CTRL_A_BRT_LSB +
> led->control_bank * 2;
>
> - led->num_leds = fwnode_property_count_u32(child, "led-sources");
> - if (led->num_leds > LM3697_MAX_LED_STRINGS) {
> + led->num_led_strings = fwnode_property_count_u32(child, "led-sources");
> + if (led->num_led_strings > LM3697_MAX_LED_STRINGS) {
> dev_err(&priv->client->dev, "Too many LED strings defined\n");
> continue;
> }
>
> ret = fwnode_property_read_u32_array(child, "led-sources",
> led->hvled_strings,
> - led->num_leds);
> + led->num_led_strings);
> if (ret) {
> dev_err(&priv->client->dev, "led-sources property missing\n");
> fwnode_handle_put(child);
> goto child_out;
> }
>
> - for (j = 0; j < led->num_leds; j++)
> + for (j = 0; j < led->num_led_strings; j++)
> priv->bank_cfg |=
> (led->control_bank << led->hvled_strings[j]);
>
> @@ -317,6 +318,8 @@ static int lm3697_probe(struct i2c_client *client,
> if (!led)
> return -ENOMEM;
>
> + led->num_leds = count;
> +
> mutex_init(&led->lock);
> i2c_set_clientdata(client, led);
>
> --
> 2.28.0
>

Marek

2020-10-05 13:52:53

[permalink] [raw]

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

Hi!

> > if (ret)
> > dev_err(&priv->client->dev, "Cannot write OUTPUT config\n");
> >
> > - for (i = 0; i < LM3697_MAX_CONTROL_BANKS; i++) {
> > + for (i = 0; i < priv->num_leds; i++) {
>
> Ultracoolguy is correct that this for cycle should not iterate
> LM3697_MAX_CONTROL_BANKS. Instead, the count check in lm3697_probe should be changed from
>
> if (!count)
> to
> if (!count || count > LM3697_MAX_CONTROL_BANKS)
>
> (the error message should also be changed, or maybe dropped, and the
> error code changed from -ENODEV to -EINVAL, if we use || operator).

I guess Dan (or someone else?) can submit simple one-liner I could
apply into -for-next (and maybe stable), and then we can sort the
naming etc in the driver? Gettings banks vs. LEDs right would be nice.

Thanks and best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:

(No filename) (982.00 B)
signature.asc (201.00 B)
Download all attachments

2020-10-05 13:59:08

[permalink] [raw]

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

I agree with you.

Attached patch with changes.

Oct 5, 2020, 12:13 by [email protected]:

> On Sat, 3 Oct 2020 15:02:51 +0200 (CEST)
> [email protected] wrote:
>
>> From 0dfd5ab647ccbc585c543d702b44d20f0e3fe436 Mon Sep 17 00:00:00 2001
>> From: Ultracoolguy <[email protected]>
>> Date: Fri, 2 Oct 2020 18:27:00 -0400
>> Subject: [PATCH] leds:lm3697:Fix out-of-bound access
>>
>> If both led banks aren't used in device tree,
>> an out-of-bounds condition in lm3697_init occurs
>> because of the for loop assuming that all the banks are used.
>> Fix it by adding a variable that contains the number of used banks.
>>
>> Signed-off-by: Ultracoolguy <[email protected]>
>> ---
>> drivers/leds/leds-lm3697.c | 15 +++++++++------
>> 1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/leds/leds-lm3697.c b/drivers/leds/leds-lm3697.c
>> index 024983088d59..a4ec2b6077e6 100644
>> --- a/drivers/leds/leds-lm3697.c
>> +++ b/drivers/leds/leds-lm3697.c
>> @@ -56,7 +56,7 @@ struct lm3697_led {
>> struct ti_lmu_bank lmu_data;
>> int control_bank;
>> int enabled;
>> - int num_leds;
>> + int num_led_strings;
>>
>
> OK, I looked at the datasheet for this controlled. The controlled can
> control 3 LED strings, each having several LEDs connected in series.
> But only 2 different brightnesses can be set (control bank), so for each
> string there is a register setting which control bank should control it.
>
> The Control Bank is set via the `reg` DT property (reg=0 means
> Control Bank A, reg=1 means Control Bank B). The `led-sources`
> property defines which strings should be controlled by each bank.
>
> So I think this variable name should stay num_leds (as in number of leds
> in this control bank).
> The structure though should be renamed:
> struct lm3697_led -> struct lm3697_bank.
>
>> };
>>
>> /**
>> @@ -78,6 +78,7 @@ struct lm3697 {
>> struct mutex lock;
>>
>> int bank_cfg;
>> + int num_leds;
>>
>
> This should be named num_banks.
>
>>
>> struct lm3697_led leds[];
>>
>
> This variable should be named banks, i.e.:
> struct lm3697_bank banks[];
>
>> };
>> @@ -180,7 +181,7 @@ static int lm3697_init(struct lm3697 *priv)
>> if (ret)
>> dev_err(&priv->client->dev, "Cannot write OUTPUT config\n");
>>
>> - for (i = 0; i < LM3697_MAX_CONTROL_BANKS; i++) {
>> + for (i = 0; i < priv->num_leds; i++) {
>>
>
> if (!count)
> to
> if (!count || count > LM3697_MAX_CONTROL_BANKS)
>
> (the error message should also be changed, or maybe dropped, and the
> error code changed from -ENODEV to -EINVAL, if we use || operator).
>
>> led = &priv->leds[i];
>> ret = ti_lmu_common_set_ramp(&led->lmu_data);
>> if (ret)
>> @@ -244,22 +245,22 @@ static int lm3697_probe_dt(struct lm3697 *priv)
>> led->lmu_data.lsb_brightness_reg = LM3697_CTRL_A_BRT_LSB +
>> led->control_bank * 2;
>>
>> - led->num_leds = fwnode_property_count_u32(child, "led-sources");
>> - if (led->num_leds > LM3697_MAX_LED_STRINGS) {
>> + led->num_led_strings = fwnode_property_count_u32(child, "led-sources");
>> + if (led->num_led_strings > LM3697_MAX_LED_STRINGS) {
>> dev_err(&priv->client->dev, "Too many LED strings defined\n");
>> continue;
>> }
>>
>> ret = fwnode_property_read_u32_array(child, "led-sources",
>> led->hvled_strings,
>> - led->num_leds);
>> + led->num_led_strings);
>> if (ret) {
>> dev_err(&priv->client->dev, "led-sources property missing\n");
>> fwnode_handle_put(child);
>> goto child_out;
>> }
>>
>> - for (j = 0; j < led->num_leds; j++)
>> + for (j = 0; j < led->num_led_strings; j++)
>> priv->bank_cfg |=
>> (led->control_bank << led->hvled_strings[j]);
>>
>> @@ -317,6 +318,8 @@ static int lm3697_probe(struct i2c_client *client,
>> if (!led)
>> return -ENOMEM;
>>
>> + led->num_leds = count;
>> +
>> mutex_init(&led->lock);
>> i2c_set_clientdata(client, led);
>>
>> --
>> 2.28.0
>>
>
> Marek
>

Attachments:

0001-leds-lm3697-Fix-out-of-bound-access.patch (7.65 kB)

2020-10-05 14:36:01

[permalink] [raw]

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

Marek

On 10/5/20 8:57 AM, [email protected] wrote:
> I agree with you.
>
> Attached patch with changes.

Nack to the patch.

The subject says it does one thing but you also unnecessarily changed
the name of the structure.

Renaming the structure does not fix the underlying issue

Dan

2020-10-05 14:41:19

[permalink] [raw]

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

All

On 10/5/20 9:33 AM, Dan Murphy wrote:
> Marek
>
Sorry not Marek but Gabriel I misread the "To" field

Dan

2020-10-05 14:41:31

[permalink] [raw]

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

I understand. So I should leave it like it was and do the rename in another patch?

Oct 5, 2020, 14:33 by [email protected]:

> Marek
>
> On 10/5/20 8:57 AM, [email protected] wrote:
>
>> I agree with you.
>>
>> Attached patch with changes.
>>
>
> Nack to the patch.
>
> The subject says it does one thing but you also unnecessarily changed the name of the structure.
>
> Renaming the structure does not fix the underlying issue
>
> Dan
>

2020-10-05 14:45:44

[permalink] [raw]

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

Gabriel

On 10/5/20 9:38 AM, [email protected] wrote:
> I understand. So I should leave it like it was and do the rename in another patch?

You should do the fix in one patch and leave the structure name alone.

The structure naming if fine and has no benefit and actually will make
it more difficult for others to backport future fixes.

Unless Pavel finds benefit in accepting the structure rename.

Dan

2020-10-05 16:03:49

[permalink] [raw]

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

Hi!

> On 10/5/20 8:57 AM, [email protected] wrote:
> > I agree with you.
> >
> > Attached patch with changes.
>
> Nack to the patch.

No need to do that, without matching From: and Signed-off, I can't
really apply it...

> The subject says it does one thing but you also unnecessarily changed the
> name of the structure.
>
> Renaming the structure does not fix the underlying issue

While I can't really apply it, it is fairly good bugreport. Can I get
minimal patch to fix the problem, that can be cc-ed to stable, and
that I can just apply with git am?

And yes, I believe renaming the structures to be non-confusing is a
very good thing, but lets make it separate patch, so that stable
backporting is easier.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:

(No filename) (921.00 B)
signature.asc (201.00 B)
Download all attachments

2020-10-05 16:08:43

[permalink] [raw]

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

Hi!

> Well, the major benefit I see is that it makes the driver slightly more readable. However I'm fine with whatever you guys decide.
>
> I'll attach the patch with the struct renaming removed just in case.

Thanks for the patches. Content is pretty good, but I'd really need
From + Signed-off-by: with your real name to be able to apply it. (I'd
avoid renaming leds->banks variable in this patch, too, so we have
minimum stable patch).

Dan is maintaining this code, I suspect he'll come up with minimum
fix + followup cleanups shortly.

Best regards,
Pavel

> diff --git a/drivers/leds/leds-lm3697.c b/drivers/leds/leds-lm3697.c
> index 024983088d59..bd53450050b2 100644
> --- a/drivers/leds/leds-lm3697.c
> +++ b/drivers/leds/leds-lm3697.c
> @@ -78,8 +78,9 @@ struct lm3697 {
> struct mutex lock;
>
> int bank_cfg;
> + int num_banks;
>
> - struct lm3697_led leds[];
> + struct lm3697_led banks[];
> };
>
> static const struct reg_default lm3697_reg_defs[] = {
> @@ -180,8 +181,8 @@ static int lm3697_init(struct lm3697 *priv)
> if (ret)
> dev_err(&priv->client->dev, "Cannot write OUTPUT config\n");
>
> - for (i = 0; i < LM3697_MAX_CONTROL_BANKS; i++) {
> - led = &priv->leds[i];
> + for (i = 0; i < priv->num_banks; i++) {
> + led = &priv->banks[i];
> ret = ti_lmu_common_set_ramp(&led->lmu_data);
> if (ret)
> dev_err(&priv->client->dev, "Setting the ramp rate failed\n");
> @@ -228,7 +229,7 @@ static int lm3697_probe_dt(struct lm3697 *priv)
> goto child_out;
> }
>
> - led = &priv->leds[i];
> + led = &priv->banks[i];
>
> ret = ti_lmu_common_get_brt_res(&priv->client->dev,
> child, &led->lmu_data);
> @@ -307,16 +308,17 @@ static int lm3697_probe(struct i2c_client *client,
> int ret;
>
> count = device_get_child_node_count(&client->dev);
> - if (!count) {
> - dev_err(&client->dev, "LEDs are not defined in device tree!");
> - return -ENODEV;
> + if (!count || count > LM3697_MAX_CONTROL_BANKS) {
> + return -EINVAL;
> }
>
> - led = devm_kzalloc(&client->dev, struct_size(led, leds, count),
> + led = devm_kzalloc(&client->dev, struct_size(led, banks, count),
> GFP_KERNEL);
> if (!led)
> return -ENOMEM;
>
> + led->num_banks = count;
> +
> mutex_init(&led->lock);
> i2c_set_clientdata(client, led);
>
> --
> 2.28.0
>

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:

(No filename) (2.49 kB)
signature.asc (201.00 B)
Download all attachments

2020-10-05 16:58:55

[permalink] [raw]

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

Well, the major benefit I see is that it makes the driver slightly more readable. However I'm fine with whatever you guys decide.

I'll attach the patch with the struct renaming removed just in case.

Oct 5, 2020, 14:41 by [email protected]:

> Gabriel
>
> On 10/5/20 9:38 AM, [email protected] wrote:
>
>> I understand. So I should leave it like it was and do the rename in another patch?
>>
>
> You should do the fix in one patch and leave the structure name alone.
>
> The structure naming if fine and has no benefit and actually will make it more difficult for others to backport future fixes.
>
> Unless Pavel finds benefit in accepting the structure rename.
>
> Dan
>

Attachments:

0001-leds-lm3697-Fix-out-of-bound-access.patch (2.20 kB)

2020-10-05 17:18:56

[permalink] [raw]

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

Agh. I added the Signed-off-by in an earlier non-published version of the commit, but forgot to add it back. But that doesn't really excuses me.

I attached the (hopefully) final version of this patch. Pavel, I'll send the struct rename separately after I submit this.

Oct 5, 2020, 16:48 by [email protected]:

> Hei hei,
>
> On Mon, Oct 05, 2020 at 05:35:38PM +0200, [email protected] wrote:
>
>> Well, the major benefit I see is that it makes the driver slightly
>> more readable. However I'm fine with whatever you guys decide.
>>
>> I'll attach the patch with the struct renaming removed just in case.
>>
>
> Note: your patch, especially the commit message, still needs a
> Signed-off-by line. Please read [1] (again?) and resend.
>
> Greets
> Alex
>
> [1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>
>> Oct 5, 2020, 14:41 by [email protected]:
>>
>> > Gabriel
>> >
>> > On 10/5/20 9:38 AM, [email protected] wrote:
>> >
>> >> I understand. So I should leave it like it was and do the rename in another patch?
>> >>
>> >
>> > You should do the fix in one patch and leave the structure name alone.
>> >
>> > The structure naming if fine and has no benefit and actually will make it more difficult for others to backport future fixes.
>> >
>> > Unless Pavel finds benefit in accepting the structure rename.
>> >
>> > Dan
>> >
>>
>> >From ee004d26bb2f91491141aa06f5518cc411711ff0 Mon Sep 17 00:00:00 2001
>> From: Ultracoolguy <[email protected]>
>> Date: Fri, 2 Oct 2020 18:27:00 -0400
>> Subject: [PATCH] leds:lm3697:Fix out-of-bound access
>>
>> If both led banks aren't used in device tree,
>> an out-of-bounds condition in lm3697_init occurs
>> because of the for loop assuming that all the banks are used.
>> Fix it by adding a variable that contains the number of used banks.
>> ---
>> drivers/leds/leds-lm3697.c | 18 ++++++++++--------
>> 1 file changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/leds/leds-lm3697.c b/drivers/leds/leds-lm3697.c
>> index 024983088d59..bd53450050b2 100644
>> --- a/drivers/leds/leds-lm3697.c
>> +++ b/drivers/leds/leds-lm3697.c
>> @@ -78,8 +78,9 @@ struct lm3697 {
>> struct mutex lock;
>>
>> int bank_cfg;
>> + int num_banks;
>>
>> - struct lm3697_led leds[];
>> + struct lm3697_led banks[];
>> };
>>
>> static const struct reg_default lm3697_reg_defs[] = {
>> @@ -180,8 +181,8 @@ static int lm3697_init(struct lm3697 *priv)
>> if (ret)
>> dev_err(&priv->client->dev, "Cannot write OUTPUT config\n");
>>
>> - for (i = 0; i < LM3697_MAX_CONTROL_BANKS; i++) {
>> - led = &priv->leds[i];
>> + for (i = 0; i < priv->num_banks; i++) {
>> + led = &priv->banks[i];
>> ret = ti_lmu_common_set_ramp(&led->lmu_data);
>> if (ret)
>> dev_err(&priv->client->dev, "Setting the ramp rate failed\n");
>> @@ -228,7 +229,7 @@ static int lm3697_probe_dt(struct lm3697 *priv)
>> goto child_out;
>> }
>>
>> - led = &priv->leds[i];
>> + led = &priv->banks[i];
>>
>> ret = ti_lmu_common_get_brt_res(&priv->client->dev,
>> child, &led->lmu_data);
>> @@ -307,16 +308,17 @@ static int lm3697_probe(struct i2c_client *client,
>> int ret;
>>
>> count = device_get_child_node_count(&client->dev);
>> - if (!count) {
>> - dev_err(&client->dev, "LEDs are not defined in device tree!");
>> - return -ENODEV;
>> + if (!count || count > LM3697_MAX_CONTROL_BANKS) {
>> + return -EINVAL;
>> }
>>
>> - led = devm_kzalloc(&client->dev, struct_size(led, leds, count),
>> + led = devm_kzalloc(&client->dev, struct_size(led, banks, count),
>> GFP_KERNEL);
>> if (!led)
>> return -ENOMEM;
>>
>> + led->num_banks = count;
>> +
>> mutex_init(&led->lock);
>> i2c_set_clientdata(client, led);
>>
>> --
>> 2.28.0
>>
>
>
> --
> /"\ ASCII RIBBON | »With the first link, the chain is forged. The first
> \ / CAMPAIGN | speech censured, the first thought forbidden, the
> X AGAINST | first freedom denied, chains us all irrevocably.«
> / \ HTML MAIL | (Jean-Luc Picard, quoting Judge Aaron Satie)
>

Attachments:

0001-leds-lm3697-Fix-out-of-bound-access.patch (2.25 kB)

2020-10-05 17:34:42

[permalink] [raw]

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

Hi!

> Agh. I added the Signed-off-by in an earlier non-published version of the commit, but forgot to add it back. But that doesn't really excuses me.
>
> I attached the (hopefully) final version of this patch.? Pavel, I'll send the struct rename separately after I submit this.
>

Thanks, I applied it with ... some tweaks. I hope I did not break it,
and would not mind testing.

Best regards,
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:

(No filename) (575.00 B)
signature.asc (201.00 B)
Download all attachments

2020-10-05 17:56:05

by Alexander Dahl

[permalink] [raw]

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

Hei hei,

On Mon, Oct 05, 2020 at 05:35:38PM +0200, [email protected] wrote:
> Well, the major benefit I see is that it makes the driver slightly
> more readable. However I'm fine with whatever you guys decide.
>
> I'll attach the patch with the struct renaming removed just in case.

Note: your patch, especially the commit message, still needs a
Signed-off-by line. Please read [1] (again?) and resend.

Greets
Alex

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html

> Oct 5, 2020, 14:41 by [email protected]:
>
> > Gabriel
> >
> > On 10/5/20 9:38 AM, [email protected] wrote:
> >
> >> I understand. So I should leave it like it was and do the rename in another patch?
> >>
> >
> > You should do the fix in one patch and leave the structure name alone.
> >
> > The structure naming if fine and has no benefit and actually will make it more difficult for others to backport future fixes.
> >
> > Unless Pavel finds benefit in accepting the structure rename.
> >
> > Dan
> >
>

> >From ee004d26bb2f91491141aa06f5518cc411711ff0 Mon Sep 17 00:00:00 2001
> From: Ultracoolguy <[email protected]>
> Date: Fri, 2 Oct 2020 18:27:00 -0400
> Subject: [PATCH] leds:lm3697:Fix out-of-bound access
>
> If both led banks aren't used in device tree,
> an out-of-bounds condition in lm3697_init occurs
> because of the for loop assuming that all the banks are used.
> Fix it by adding a variable that contains the number of used banks.
> ---
> drivers/leds/leds-lm3697.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/leds/leds-lm3697.c b/drivers/leds/leds-lm3697.c
> index 024983088d59..bd53450050b2 100644
> --- a/drivers/leds/leds-lm3697.c
> +++ b/drivers/leds/leds-lm3697.c
> @@ -78,8 +78,9 @@ struct lm3697 {
> struct mutex lock;
>
> int bank_cfg;
> + int num_banks;
>
> - struct lm3697_led leds[];
> + struct lm3697_led banks[];
> };
>
> static const struct reg_default lm3697_reg_defs[] = {
> @@ -180,8 +181,8 @@ static int lm3697_init(struct lm3697 *priv)
> if (ret)
> dev_err(&priv->client->dev, "Cannot write OUTPUT config\n");
>
> - for (i = 0; i < LM3697_MAX_CONTROL_BANKS; i++) {
> - led = &priv->leds[i];
> + for (i = 0; i < priv->num_banks; i++) {
> + led = &priv->banks[i];
> ret = ti_lmu_common_set_ramp(&led->lmu_data);
> if (ret)
> dev_err(&priv->client->dev, "Setting the ramp rate failed\n");
> @@ -228,7 +229,7 @@ static int lm3697_probe_dt(struct lm3697 *priv)
> goto child_out;
> }
>
> - led = &priv->leds[i];
> + led = &priv->banks[i];
>
> ret = ti_lmu_common_get_brt_res(&priv->client->dev,
> child, &led->lmu_data);
> @@ -307,16 +308,17 @@ static int lm3697_probe(struct i2c_client *client,
> int ret;
>
> count = device_get_child_node_count(&client->dev);
> - if (!count) {
> - dev_err(&client->dev, "LEDs are not defined in device tree!");
> - return -ENODEV;
> + if (!count || count > LM3697_MAX_CONTROL_BANKS) {
> + return -EINVAL;
> }
>
> - led = devm_kzalloc(&client->dev, struct_size(led, leds, count),
> + led = devm_kzalloc(&client->dev, struct_size(led, banks, count),
> GFP_KERNEL);
> if (!led)
> return -ENOMEM;
>
> + led->num_banks = count;
> +
> mutex_init(&led->lock);
> i2c_set_clientdata(client, led);
>
> --
> 2.28.0
>

--
/"\ ASCII RIBBON | ?With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
X AGAINST | first freedom denied, chains us all irrevocably.?
/ \ HTML MAIL | (Jean-Luc Picard, quoting Judge Aaron Satie)

Attachments:

(No filename) (3.65 kB)
signature.asc (849.00 B)
Download all attachments

2020-10-05 18:34:20

[permalink] [raw]

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

Otherwise everything works great :)

(And sorry for sending two emails)

Oct 5, 2020, 18:29 by [email protected]:

> This:
>
> led->num_banks = count;
>
> Has to be below devm_kzalloc. Else, it's NULL.
> Oct 5, 2020, 17:32 by [email protected]:
>
>> Hi!
>>
>>> Agh. I added the Signed-off-by in an earlier non-published version of the commit, but forgot to add it back. But that doesn't really excuses me.
>>>
>>> I attached the (hopefully) final version of this patch. Pavel, I'll send the struct rename separately after I submit this.
>>>
>>
>> Thanks, I applied it with ... some tweaks. I hope I did not break it,
>> and would not mind testing.
>>
>> Best regards,
>> Pavel
>>
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>
>
>

2020-10-05 20:32:35

[permalink] [raw]

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

This:

led->num_banks = count;

Has to be below devm_kzalloc. Else, it's NULL.
Oct 5, 2020, 17:32 by [email protected]:

> Hi!
>
>> Agh. I added the Signed-off-by in an earlier non-published version of the commit, but forgot to add it back. But that doesn't really excuses me.
>>
>> I attached the (hopefully) final version of this patch. Pavel, I'll send the struct rename separately after I submit this.
>>
>
> Thanks, I applied it with ... some tweaks. I hope I did not break it,
> and would not mind testing.
>
> Best regards,
> Pavel
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

2020-10-05 20:33:15

[permalink] [raw]

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

On Mon 2020-10-05 20:31:16, [email protected] wrote:
> Otherwise everything works great :)
>
> (And sorry for sending two emails)

No problem, sorry for breaking your patch. I moved it near other
initializers.

Question: is it likely that someone will want to use your device with
-stable kernels? Should I mark this for -stable?

Thanks and best regards,

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:

(No filename) (534.00 B)
signature.asc (201.00 B)
Download all attachments

2020-10-05 20:34:04

[permalink] [raw]

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

>No problem, sorry for breaking your patch. I moved it near other
initializers.

No problem :)

>Question: is it likely that someone will want to use your device with
-stable kernels? Should I mark this for -stable?

To be honest, it's unlikely that someone other than me is interested in my device on -stable. However, if you feel like the patch is simple enough to not cause any problem, then feel free to do so.

Oct 5, 2020, 18:39 by [email protected]:

> On Mon 2020-10-05 20:31:16, [email protected] wrote:
>
>> Otherwise everything works great :)
>>
>> (And sorry for sending two emails)
>>
>
> No problem, sorry for breaking your patch. I moved it near other
> initializers.
>
> Question: is it likely that someone will want to use your device with
> -stable kernels? Should I mark this for -stable?
>
> Thanks and best regards,
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

2020-10-06 07:35:26

[permalink] [raw]

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

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.

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...

Marek

2020-10-06 12:03:00

[permalink] [raw]

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

While I do agree with you that having the child nodes be led strings make more sense, would it be possible to have, for example, three strings controlled by the same label?

Oct 6, 2020, 07:33 by [email protected]:

> 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.
>
> 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...
>
> Marek
>

2020-10-06 12:24:17

[permalink] [raw]

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

All

On 10/6/20 6:59 AM, [email protected] wrote:
> While I do agree with you that having the child nodes be led strings make more sense, would it be possible to have, for example, three strings controlled by the same label?
>
> Oct 6, 2020, 07:33 by [email protected]:
>
>> 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

2020-10-06 14:43:47

[permalink] [raw]

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 <[email protected]> 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

2020-10-06 15:00:23

[permalink] [raw]

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

Marek

On 10/6/20 9:41 AM, Marek Behun wrote:
> Adding Rob to Cc, Rob, could we have your opinion on this? Mine is below.
>
> 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.

Unfortunately we cannot and should not change the ABI now.

Using the led-sources as the bank indicator does not conform to the
definition of the description of the led-sources in the yaml.

The preference was to use the led-sources to define the LED out to the bank.

Here is the conversation on how the driver got to where it is.

https://lore.kernel.org/patchwork/patch/972337/

Dan

2020-10-06 15:15:51

[permalink] [raw]

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

On Tue, 6 Oct 2020 09:57:08 -0500
Dan Murphy <[email protected]> wrote:

> Unfortunately we cannot and should not change the ABI now.
>
> Using the led-sources as the bank indicator does not conform to the
> definition of the description of the led-sources in the yaml.
>
> The preference was to use the led-sources to define the LED out to the bank.
>
> Here is the conversation on how the driver got to where it is.
>
> https://lore.kernel.org/patchwork/patch/972337/
>
> Dan
>

Oh, if this was discussed already, then never mind. Sorry for taking
your time.

Marek

2020-10-06 17:30:19