linux-kernel - Re: [PATCH v2] gpiolib: Fix possible use after free on label

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:   Thu, 1 Nov 2018 16:27:58 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     smuchun@...il.com, Nicolas Pitre <nico@...aro.org>
Cc:     Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] gpiolib: Fix possible use after free on label

On Thu, Nov 1, 2018 at 2:13 PM Muchun Song <smuchun@...il.com> wrote:

> gpiod_request_commit() copies the pointer to the label passed as
> an argument only to be used later. But there's a chance the caller
> could immediately free the passed string(e.g., local variable).
> This could trigger a use after free when we use gpio label(e.g.,
> gpiochip_unlock_as_irq(), gpiochip_is_requested()).
>
> To be on the safe side: duplicate the string with kstrdup_const()
> so that if an unaware user passes an address to a stack-allocated
> buffer, we won't get the arbitrary label.
>
> Also fix gpiod_set_consumer_name().
>
> Signed-off-by: Muchun Song <smuchun@...il.com>

I am still a bit worried about the kstrdup_const() that this
introduces. The tinyfication people will not like that we now
copy every GPIO line name from the device tree into a
new reference copy.

What we *REALLY* want to do is:

const char *str;
const char *ref;

if (pointer_on_stack(str))
   ref = kstrdup_const(str);
else
   ref = str;

Isn't this possible to achieve somehow? If not, why not?
I suspect maybe there is no simple solution to this, but
what about a really complicated and hard solution?

I'm looping in Nico for advice.

Maybe I will end up applying it anyway but I'm not sure.
The patch looks good otherwise.

Yours,
Linus Walleij