All of lore.kernel.org
 help / color / mirror / Atom feed
From: Drew Fustini <drew@beagleboard.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	Jason Kridner <jkridner@beagleboard.org>,
	Robert Nelson <robertcnelson@beagleboard.org>
Subject: Re: [PATCH v2 2/2] pinctrl: pinmux: Add pinmux-select debugfs file
Date: Wed, 10 Feb 2021 09:31:00 -0800	[thread overview]
Message-ID: <20210210173100.GA178344@x1> (raw)
In-Reply-To: <CAHp75VcDVVZ=hg5hfRTs9hJ20gdEE_Xhccyg859nsvtyxTXCyw@mail.gmail.com>

On Wed, Feb 10, 2021 at 11:56:49AM +0200, Andy Shevchenko wrote:
> On Wed, Feb 10, 2021 at 9:50 AM Drew Fustini <drew@beagleboard.org> wrote:
> >
> > Add "pinmux-select" to debugfs which will activate a function and group
> > when 2 integers "<function-selector> <group-selector>" are written to
> > the file. The write operation pinmux_select() handles this by checking
> > if fsel and gsel are valid selectors and then calling ops->set_mux().
> >
> > The existing "pinmux-functions" debugfs file lists the pin functions
> > registered for the pin controller. For example:
> >
> > function: pinmux-uart0, groups = [ pinmux-uart0-pins ]
> > function: pinmux-mmc0, groups = [ pinmux-mmc0-pins ]
> > function: pinmux-mmc1, groups = [ pinmux-mmc1-pins ]
> > function: pinmux-i2c0, groups = [ pinmux-i2c0-pins ]
> > function: pinmux-i2c1, groups = [ pinmux-i2c1-pins ]
> > function: pinmux-spi1, groups = [ pinmux-spi1-pins ]
> >
> > To activate function pinmux-i2c1 (fsel 4) and group pinmux-i2c1-pins
> > (gsel 4):
> >
> > echo '4 4' > pinmux-select
> 
> ...
> 
> >  DEFINE_SHOW_ATTRIBUTE(pinmux_pins);
> >
> 
> > +
> 
> One blank line (existed) is enough.
> 
> > +#define PINMUX_MAX_NAME 64
> 
> ...
> 
> > +       buf = devm_kzalloc(pctldev->dev, PINMUX_MAX_NAME * 2, GFP_KERNEL);
> 
> You have to (re-)read documentation about Device Managed Resources.
> Keyword here is *device*! Pay attention to it. TL;DR: misuse of device
> managed resources here.
> Potentially memory exhausting (local DoS attack), but see below.
> 
> > +       if (!buf)
> > +               return -ENOMEM;
> 
> ...
> 
> > +       devm_kfree(pctldev->dev, buf);
> 
> Calling devm_kfree() or other devm_*() release kinda APIs is a red
> flag in 99%. See above.

Thank you for reviewing and pointing out this issue.

Do you mean that I should not be treating these buffers used in the 
debugfs write op as belonging to the pin controller device?

I have looked through the kernel code and I realize now that I don't see
any instances of devm_*() being used inside the read or write op for a
debugfs file. As I consider it further, devm_*() does not seem to make
sense as I am creating the buffers only for temporary use inside
pinmux_select().

I'll get that fixed in v3.

Thank you,
Drew

  reply	other threads:[~2021-02-10 17:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10  7:49 [PATCH v2 0/2] pinctrl: pinmux: Add pinmux-select debugfs file Drew Fustini
2021-02-10  7:49 ` [PATCH v2 1/2] pinctrl: use to octal permissions for debugfs files Drew Fustini
2021-02-10  8:30   ` Joe Perches
2021-02-10 10:18     ` Andy Shevchenko
2021-02-10 12:36       ` Joe Perches
2021-02-10 21:21         ` Drew Fustini
2021-02-10 23:12           ` Joe Perches
2021-02-10  8:31   ` Geert Uytterhoeven
2021-02-10 10:14     ` Andy Shevchenko
2021-02-10 10:16   ` Andy Shevchenko
2021-02-10  7:49 ` [PATCH v2 2/2] pinctrl: pinmux: Add pinmux-select debugfs file Drew Fustini
2021-02-10  8:35   ` Geert Uytterhoeven
2021-02-10  9:56   ` Andy Shevchenko
2021-02-10 17:31     ` Drew Fustini [this message]
2021-02-10 18:20   ` Dan Carpenter
2021-02-10 18:20     ` Dan Carpenter
2021-02-10 18:20     ` Dan Carpenter
2021-02-10 18:39     ` Geert Uytterhoeven
2021-02-10 18:39       ` Geert Uytterhoeven
2021-02-10 19:05       ` Dan Carpenter
2021-02-10 19:05         ` Dan Carpenter
2021-02-10 19:05         ` Dan Carpenter
2021-02-10 19:14         ` Drew Fustini
2021-02-10 19:04     ` Drew Fustini
2021-02-10 20:33       ` Dan Carpenter
2021-02-10 20:33         ` Dan Carpenter
2021-02-10 20:33         ` Dan Carpenter
2021-02-10 15:29 kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210210173100.GA178344@x1 \
    --to=drew@beagleboard.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=jkridner@beagleboard.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=robertcnelson@beagleboard.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.