linux-kernel - Re: [PATCH] gpio: Restrict usage of gc irq members before initialization

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:   Fri, 11 Mar 2022 19:29:59 +0530
From:   Shreeya Patel <shreeya.patel@...labora.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>, krisman@...labora.com,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Collabora Kernel ML <kernel@...labora.com>
Subject: Re: [PATCH] gpio: Restrict usage of gc irq members before
 initialization


On 10/03/22 8:14 pm, Andy Shevchenko wrote:
> On Thu, Mar 10, 2022 at 3:22 PM Shreeya Patel
> <shreeya.patel@...labora.com> wrote:
>> gc irq members are exposed before they could be completely
>> initialized and this leads to race conditions.
>>
>> One such issue was observed for the gc->irq.domain variable which
>> was accessed through the I2C interface in gpiochip_to_irq() before
>> it could be initialized by gpiochip_add_irqchip(). This resulted in
>> Kernel NULL pointer dereference.
>>
>> To avoid such scenarios, restrict usage of gc irq members before
>> they are completely initialized.
> Fixes tag?
>
> ...


We don't really have any specific commit which introduces this issue so
I did not add fixes tag here.

>> +bool gc_irq_initialized;
> Non-static?
>
> Why is it global?
>
> ...
>
>> @@ -1593,6 +1594,8 @@ static int gpiochip_add_irqchip(struct gpio_chip *gc,
>>
>>          acpi_gpiochip_request_interrupts(gc);
>>
>> +       gc_irq_initialized = true;
> This is wrong. Imagine a system where you have more than one GPIO chip.
>
> ...


Yes, thanks for pointing it out. This flag introduced should be a member of
gpio_chip structure as mentioned by Gabriel and then it should work for
multiple gpio chips as well.

>> -       if (gc->to_irq) {
>> +       if (gc->to_irq && gc_irq_initialized) {
>>                  int retirq = gc->to_irq(gc, offset);
> Shouldn't it rather be something like
>
>    if (gc->to_irq) {
>      if (! ..._initialized)
>        return -EPROBE_DEFER;
>      ...
>    }
>
> ?


No, the above code will still bring in issues when gc->to_irq is NULL
and will return -ENXIO. We have seen race in registering of gc->to_irq
as well which is why we had introduced the following patch as the first 
step.

https://lore.kernel.org/lkml/20220216202655.194795-1-shreeya.patel@collabora.com/t/


Thanks,
Shreeya Patel

>
> --
> With Best Regards,
> Andy Shevchenko