mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Fabio Estevam <festevam@gmail.com>
Cc: matthias.schiffer@ew.tq-group.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] regmap: debugfs: Free debugfs_name buffer after usage
Date: Thu, 6 Jan 2022 18:33:52 +0000	[thread overview]
Message-ID: <Ydc2EHf5f12w4YcW@sirena.org.uk> (raw)
In-Reply-To: <20220106175019.3116389-1-festevam@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On Thu, Jan 06, 2022 at 02:50:19PM -0300, Fabio Estevam wrote:

> The reason for the duplicate name is that map->debugfs_name is never freed,
> which can cause a directory to be created with the same name used in the
> previous debugfs entry allocation.

> Fix this problem by freeing map->debugfs_name and setting it to NULL
> after its usage.

OK, but what's the logic here?  The name is getting thrown away here but
clearly there is a file still so I'm not seeing how anything is going to
clean that file up.  That means that if the device gets freed we'll end
up with the old debugfs file hanging around pointing at nothing.  Like I
said (originally in response to Matthias' patch but pasted in this
thread as well):

| (we should probably clean up the one with no device but that's not what
| your commit does).  I think what you need to look at here is that we

The use after free extends beyond just the filename, we're also loosing
track of the already created file, which does seem to be an existing
bug.  To be more explicit this means we need a call to regmap_debugfs_exit()
which will clean up all the existing debugfs stuff before we loose
references to it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-01-06 18:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06 17:50 Fabio Estevam
2022-01-06 18:33 ` Mark Brown [this message]
2022-01-06 19:27   ` Fabio Estevam
2022-01-06 20:05     ` Mark Brown
2022-01-06 21:13       ` Fabio Estevam
2022-01-07  2:22         ` Fabio Estevam
2022-01-07 13:27           ` Mark Brown
2022-01-07 14:48             ` Fabio Estevam
2022-01-07 14:52               ` Mark Brown

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=Ydc2EHf5f12w4YcW@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=festevam@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.schiffer@ew.tq-group.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®