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: <CACRpkdaURruTj6W=ozXpKEvLpxLa=6tLdDywac1uj61Hg8ZKpA@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ