linux-kernel - Re: [PATCH] gpio: 74x164: Fix crash during .remove()

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: <CAOMZO5CCurrpWx3twLfPeGnGTuV3fP+vZAA24=JTXZUBRSBMEg@mail.gmail.com>
Date:   Tue, 21 Nov 2017 12:27:22 -0200
From:   Fabio Estevam <festevam@...il.com>
To:     Geert Uytterhoeven <geert+renesas@...der.be>
Cc:     Fabio Estevam <fabio.estevam@....com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: 74x164: Fix crash during .remove()

On Tue, Nov 21, 2017 at 12:18 PM, Geert Uytterhoeven
<geert+renesas@...der.be> wrote:
> Commit 7ebc194d0fd4bb0f ("gpio: 74x164: Introduce 'enable-gpios'
> property") added a new member gpiod_oe to the end of the struct
> gen_74x164_chip, after the zero-length buffer array.
>
> However, this buffer is a flexible array, allocated together with the
> structure during .probe().  As the buffer is no longer the last member,
> writing to it corrupts the newly added member after it.
> During device removal, the corrupted member will be used as a pointer,
> leading to a crash.
>
> This went unnoticed, as the flexible array was declared as "buffer[0]"
> instead of "buffer[]", and thus did not trigger a "flexible array member
> not at end of struct" error from gcc.
>
> Move the gpiod_oe field up to fix this, and drop the zero from the array
> size to prevent future similar bugs.
>
> Fixes: 7ebc194d0fd4bb0f ("gpio: 74x164: Introduce 'enable-gpios' property")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>

Thanks for the fix:

Reviewed-by: Fabio Estevam <fabio.estevam@....com>