From: Thierry Reding <treding@nvidia.com>
To: Bitan Biswas <bbiswas@nvidia.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh@kernel.org>, <linux-kernel@vger.kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>
Subject: Re: [PATCH V1] nvmem: core: fix memory abort in cleanup path
Date: Fri, 3 Jan 2020 08:11:52 +0100 [thread overview]
Message-ID: <20200103071152.GA1933715@ulmo> (raw)
In-Reply-To: <7abb79c6-b497-98b3-45ff-44d751f1c781@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]
On Thu, Jan 02, 2020 at 10:51:24AM -0800, Bitan Biswas wrote:
>
> Hi Thierry,
>
> On 1/2/20 4:44 AM, Thierry Reding wrote:
> > On Sat, Dec 28, 2019 at 08:02:42PM -0800, Bitan Biswas wrote:
> > > nvmem_cell_info_to_nvmem_cell implementation has static
> > > allocation of name. nvmem_add_cells_from_of() call may
> > > return error and kfree name results in memory abort. Use
> > > kasprintf() instead of assigning pointer and prevent kfree crash.
> > >
> > > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > > index 9f1ee9c..0fc66e1 100644
> > > --- a/drivers/nvmem/core.c
> > > +++ b/drivers/nvmem/core.c
> > > @@ -110,7 +110,7 @@ static int nvmem_cell_info_to_nvmem_cell(struct nvmem_device *nvmem,
> > > cell->nvmem = nvmem;
> > > cell->offset = info->offset;
> > > cell->bytes = info->bytes;
> > > - cell->name = info->name;
> > > + cell->name = kasprintf(GFP_KERNEL, "%s", info->name);
>
> >
> > kstrdup() seems more appropriate here.
> Thanks. I shall update the patch as suggested.
>
> >
> > A slightly more efficient way to do this would be to use a combination
> > of kstrdup_const() and kfree_const(), which would allow read-only
> > strings to be replicated by simple assignment rather than duplication.
> > Note that in that case you'd need to carefully replace all kfree() calls
> > on cell->name by a kfree_const() to ensure they do the right thing.
> kfree(cell->name) is also called for allocations in function
> nvmem_add_cells_from_of() through below call
> kasprintf(GFP_KERNEL, "%pOFn", child);
>
> My understanding is kfree_const may not work for above allocation.
kfree_const() checks the location that the pointer passed to it points
to. If it points to the kernel's .rodata section, it returns and only
calls kfree() otherwise. Similarily, kstrdup_const() returns its
argument if it points to the .rodata section and duplicates the string
otherwise. On the other hand, pointers returned by kasprintf() will
never point to the .rodata section, so kfree_const() will result in
kfree() getting called.
That said, the savings here are fairly minimal, so I don't feel very
strongly about this. Feel free to go with the kstrdup() variant.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-01-03 7:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-29 4:02 [PATCH V1] nvmem: core: fix memory abort in cleanup path Bitan Biswas
2020-01-02 12:44 ` Thierry Reding
2020-01-02 18:51 ` Bitan Biswas
2020-01-03 7:11 ` Thierry Reding [this message]
2020-01-03 12:50 ` Bitan Biswas
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=20200103071152.GA1933715@ulmo \
--to=treding@nvidia.com \
--cc=bbiswas@nvidia.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
/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