linux-kernel - Re: [RFC PATCH] leds: core: Fix LED_COLOR_MAX

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] [day] [month] [year] [list]

Date:   Wed, 2 Oct 2019 13:42:36 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Pavel Machek <pavel@....cz>
CC:     <jacek.anaszewski@...il.com>, <linux-leds@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] leds: core: Fix LED_COLOR_MAX_ID

Hello

On 10/2/19 1:36 PM, Pavel Machek wrote:
> On Wed 2019-10-02 11:34:00, Dan Murphy wrote:
>> The LED_COLOR_MAX_ID is incorrect.  THe MAX_ID should
>> be the last COLOR_ID in the list.  If an array was allocate
>> with MAX_ID the allocation would be correct but the meaning
>> is wrong.
>>
>> So for array allocation the code should use LED_NUM_COLOR_IDS
>> which will allocate MAX_ID + 1.  Whent the code needs to validate
>> that the color ID is not out of bounds then the code should use
>> LED_COLOR_MAX_ID.
> Renaming original define might have been okay. Having two defines is
> not. I'd say we can keep it as is...

OK.  It was just not logical that MAX_ID will always be 1 more then the 
actual MAX_ID.

So every ID boundary check will need to be ">=" as opposed to ">" which 
means we have to take care in reviews to make sure this is what is intended.

But it was just a RFC so I am not pushing this fix.  It would mean I 
would have to re-touch the MC framework patches.

Dan


>
> 								Pavel
>