linux-kernel - Re: [PATCH] gpio: davinci: Fix potential buffer overflow

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: <6d228b37-fec7-4a0c-b888-6311c5e17c24@intel.com>
Date: Thu, 28 Mar 2024 17:32:53 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Aleksandr Mishin <amishin@...rgos.ru>
CC: Keerthy <j-keerthy@...com>, Linus Walleij <linus.walleij@...aro.org>,
	Bartosz Golaszewski <brgl@...ev.pl>, "Andrew F. Davis" <afd@...com>,
	<linux-gpio@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<"<lvc-project"@linuxtesting.org>
Subject: Re: [PATCH] gpio: davinci: Fix potential buffer overflow

From: Aleksandr Mishin <amishin@...rgos.ru>
Date: Thu, 28 Mar 2024 19:23:56 +0300

> 
> 
> 28.03.2024 18:27, Alexander Lobakin пишет:
>> From: Aleksandr Mishin <amishin@...rgos.ru>
>> Date: Thu, 28 Mar 2024 12:10:21 +0300
>>
>>> In davinci_gpio_probe() accessing an element of array 'chips->regs'
>>> of size 5 and
>>> array 'offset_array' of size 5 can lead to a buffer overflow, since
>>> the index
>>> 'bank' can have an out of range value 63.
>>> Fix this bug by limiting top index value.
>>>
>>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>>
>>> Fixes: c809e37a3b5a ("gpio: davinci: Allocate the correct amount of
>>> memory for controller")
>>> Signed-off-by: Aleksandr Mishin <amishin@...rgos.ru>
>>> ---
>>>   drivers/gpio/gpio-davinci.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
>>> index bb499e362912..b65df1f2b83f 100644
>>> --- a/drivers/gpio/gpio-davinci.c
>>> +++ b/drivers/gpio/gpio-davinci.c
>>> @@ -257,6 +257,9 @@ static int davinci_gpio_probe(struct
>>> platform_device *pdev)
>>>       spin_lock_init(&chips->lock);
>>>         nbank = DIV_ROUND_UP(ngpio, 32);
>>> +    if (nbank > MAX_REGS_BANKS || nbank > 5) {
>>> +        nbank = MAX_REGS_BANKS < 5 ? MAX_REGS_BANKS : 5;
>>> +    }
>>
>> Static analysis warnings make no sense until you provide a reliable way
>> to trigger the problem on real systems.
>>
>>>       for (bank = 0; bank < nbank; bank++)
>>>           chips->regs[bank] = gpio_base + offset_array[bank];
>>>   
>>
>> Thanks,
>> Olek
>>
> 
> I can only see the code at this time. And I see the following:
> 1. In some configurations CONFIG_ARCH_NR_GPIO value is 2048. So nbank
> value can be 64.
> 2. Previously, a patch was proposed that removes restrictions on the
> number of GPIOs
> (https://lore.kernel.org/all/cb540a9d73cad36d288664f8b275c6308a4a3168.1662116601.git.christophe.leroy@csgroup.eu/).
> 

But no real hardware / device tree which declares such huge number of
GPIOs, right?

CONFIG_ARCH_NR_GPIO is architecture-specific. Davinci is a platform, not
an architecture. If no Davinci board can have a number that would
overflow, the fix doesn't make sense.

Thanks,
Olek