linux-kernel - Re: [PATCH] leds: fix a potential NULL pointer dereference

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: <CAMuHMdU9X2ah6q-RhqbAZnyaw9PHOsD5Q=Y9wmTU_uzJ0MLyuA@mail.gmail.com>
Date:   Mon, 1 Apr 2019 09:08:23 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     Kangjie Lu <kjlu@....edu>, pakki001@....edu,
        Riku Voipio <riku.voipio@....fi>, Pavel Machek <pavel@....cz>,
        linux-leds@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] leds: fix a potential NULL pointer dereference

Hi Jacek,

On Sun, Mar 31, 2019 at 1:01 PM Jacek Anaszewski
<jacek.anaszewski@...il.com> wrote:
> On 3/31/19 11:06 AM, Geert Uytterhoeven wrote:
> On Sun, Mar 10, 2019 at 9:40 PM Jacek Anaszewski
> > <jacek.anaszewski@...il.com> wrote:
> >> On 3/9/19 7:04 AM, Kangjie Lu wrote:
> >>> In case of_match_device cannot find a match, the fixes returns
> >>> -EINVAL to avoid NULL pointer dereference.
> >>>
> >>> Signed-off-by: Kangjie Lu <kjlu@....edu>
> >>> ---
> >>>    drivers/leds/leds-pca9532.c | 8 ++++++--
> >>>    1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
> >>> index 7fea18b0c15d..4b0335591728 100644
> >>> --- a/drivers/leds/leds-pca9532.c
> >>> +++ b/drivers/leds/leds-pca9532.c
> >>> @@ -513,6 +513,7 @@ static int pca9532_probe(struct i2c_client *client,
> >>>        const struct i2c_device_id *id)
> >>>    {
> >>>        int devid;
> >>> +     const struct of_device_id *of_id;
> >>>        struct pca9532_data *data = i2c_get_clientdata(client);
> >>>        struct pca9532_platform_data *pca9532_pdata =
> >>>                        dev_get_platdata(&client->dev);
> >>> @@ -528,8 +529,11 @@ static int pca9532_probe(struct i2c_client *client,
> >>>                        dev_err(&client->dev, "no platform data\n");
> >>>                        return -EINVAL;
> >>>                }
> >>> -             devid = (int)(uintptr_t)of_match_device(
> >>> -                     of_pca9532_leds_match, &client->dev)->data;
> >>> +             of_id = of_match_device(of_pca9532_leds_match,
> >>> +                             &client->dev);
> >>> +             if (unlikely(!of_id))
> >
> > Use of unlikey() is frowned upon.
>
> What do you mean? Can you give some reference?

I have more memories of this being discussed, but I could find only
https://lwn.net/Articles/420019/

It may be useful for some heavily used core code, but not in most drivers
or uncritical code like probe paths, due to:
  - many people getting it wrong,
  - usually it doesn't make any difference at all.

> >> Applied to the for-5.2 branch of linux-leds.git.
> >
> > And also as a fix for v5.1...
>
> Yes, but it had been in linux-next for almost two weeks before that.

Sorry, I only noticed when it got upstream.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds