linux-kernel - Re: [PATCH V2] mmc: core: cd_label must be last entry of mmc

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:   Mon, 2 Jul 2018 13:42:26 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Anson Huang <Anson.Huang@....com>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Adrian Hunter <adrian.hunter@...el.com>, evgreen@...omium.org,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Fabio Estevam <fabio.estevam@....com>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        NXP Linux Team <Linux-imx@....com>
Subject: Re: [PATCH V2] mmc: core: cd_label must be last entry of mmc_gpio struct

On Mon, Jul 2, 2018 at 3:32 AM Anson Huang <Anson.Huang@....com> wrote:

> commit bfd694d5e21c ("mmc: core: Add tunable delay
> before detecting card after card is inserted") adds
> "u32 cd_debounce_delay_ms" to the last of mmc_gpio
> struct and cause "char cd_label[0]" NOT work as string
> pointer of card detect label, when "cat /proc/interrupts",
> the devname for card detect gpio is incorrect as below:
>
> 144:          0  gpio-mxc  22 Edge      ▒
> 161:          0  gpio-mxc   7 Edge      ▒
>
> Move the cd_label field down to fix this, and drop the
> zero from the array size to prevent future similar bugs,
> the result is correct as below:
>
> 144:          0  gpio-mxc  22 Edge      2198000.mmc cd
> 161:          0  gpio-mxc   7 Edge      2190000.mmc cd
>
> Fixes: bfd694d5e21c ("mmc: core: Add tunable delay before detecting card after card is inserted")
> Signed-off-by: Anson Huang <Anson.Huang@....com>
> Tested-by: Fabio Estevam <fabio.estevam@....com>

Curious.

> --- a/drivers/mmc/core/slot-gpio.c
> +++ b/drivers/mmc/core/slot-gpio.c
> @@ -27,8 +27,8 @@ struct mmc_gpio {
>         bool override_cd_active_level;
>         irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
>         char *ro_label;
> -       char cd_label[0];
>         u32 cd_debounce_delay_ms;
> +       char cd_label[];

Not that I am the smartest in the world when it comes to how the
C compilers work this out.

But isn't that equivalent to:
char *cd_label;
?

Look at this from drivers/mmc/core/slot-gpio.c:

ctx->ro_label = ctx->cd_label + len;
ctx->cd_debounce_delay_ms = 200;
snprintf(ctx->cd_label, len, "%s cd", dev_name(host->parent));
snprintf(ctx->ro_label, len, "%s ro", dev_name(host->parent));
host->slot.handler_priv = ctx;
host->slot.cd_irq = -EINVAL;

So now that ro_label is char * that points len chars into the
struct and that is all fine as the ctx is allocated like that:

struct mmc_gpio *ctx = devm_kzalloc(host->parent,
                               sizeof(*ctx) + 2 * len, GFP_KERNEL);

And I've seen this being done to allocate a state with
some dynamic strings after it.

But I just don't like this, it seems fragile and now it broke.

What about this:

>From facb3799f479bfd4dad99c25c9c5d4c77b14c9b0 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij@...aro.org>
Date: Mon, 2 Jul 2018 13:35:01 +0200
Subject: [PATCH] mmc: slot-gpio: Allocate GPIO labels dynamically

The use of string pointers in the MMC slot GPIO context is
pretty dubious, allocating some 2*len extra bytes for each
label of the ro and wp pins.

Tidy this up using kasprintf() with dynamic allocation of
labels for these strings.

Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
---
 drivers/mmc/core/slot-gpio.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index ef05e0039378..c417801b366e 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -27,7 +27,7 @@ struct mmc_gpio {
     bool override_cd_active_level;
     irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
     char *ro_label;
-    char cd_label[0];
+    char *cd_label;
     u32 cd_debounce_delay_ms;
 };

@@ -47,13 +47,18 @@ int mmc_gpio_alloc(struct mmc_host *host)
 {
     size_t len = strlen(dev_name(host->parent)) + 4;
     struct mmc_gpio *ctx = devm_kzalloc(host->parent,
-                sizeof(*ctx) + 2 * len,    GFP_KERNEL);
+                        sizeof(*ctx), GFP_KERNEL);

     if (ctx) {
-        ctx->ro_label = ctx->cd_label + len;
         ctx->cd_debounce_delay_ms = 200;
-        snprintf(ctx->cd_label, len, "%s cd", dev_name(host->parent));
-        snprintf(ctx->ro_label, len, "%s ro", dev_name(host->parent));
+        ctx->cd_label = devm_kasprintf(host->parent, GFP_KERNEL,
+                "%s cd", dev_name(host->parent));
+        if (!ctx->cd_label)
+            return -ENOMEM;
+        ctx->ro_label = devm_kasprintf(host->parent, GFP_KERNEL,
+                "%s ro", dev_name(host->parent));
+        if (!ctx->ro_label)
+            return -ENOMEM;
         host->slot.handler_priv = ctx;
         host->slot.cd_irq = -EINVAL;
     }
-- 
2.17.0

I can send it as a separate patch if you like it.

Yours,
Linus Walleij