From: Johannes Thumshirn <jthumshirn@suse.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-gpio@vger.kernel.org
Subject: Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails
Date: Wed, 12 Oct 2016 10:30:02 +0200 [thread overview]
Message-ID: <20161012083002.c4tsiuis4suna77h@linux-x5ow.site> (raw)
In-Reply-To: <20161012081422.GA27222@mwanda>
On Wed, Oct 12, 2016 at 11:14:22AM +0300, Dan Carpenter wrote:
> Hello Johannes Thumshirn,
>
> The patch e1547af8c059: "pinctrl: berlin: Don't leak memory if
> krealloc() fails" from Sep 30, 2016, leads to the following static
> checker warning:
>
> drivers/pinctrl/berlin/berlin.c:244 berlin_pinctrl_build_state()
> warn: passing devm_ allocated variable to kfree. 'pctrl->functions'
>
> drivers/pinctrl/berlin/berlin.c
> 221
> 222 /* we will reallocate later */
> 223 pctrl->functions = devm_kzalloc(&pdev->dev,
> 224 max_functions * sizeof(*pctrl->functions),
> 225 GFP_KERNEL);
> 226 if (!pctrl->functions)
> 227 return -ENOMEM;
> 228
> 229 /* register all functions */
> 230 for (i = 0; i < pctrl->desc->ngroups; i++) {
> 231 desc_group = pctrl->desc->groups + i;
> 232 desc_function = desc_group->functions;
> 233
> 234 while (desc_function->name) {
> 235 berlin_pinctrl_add_function(pctrl, desc_function->name);
> 236 desc_function++;
> 237 }
> 238 }
> 239
> 240 functions = krealloc(pctrl->functions,
> 241 pctrl->nfunctions * sizeof(*pctrl->functions),
> 242 GFP_KERNEL);
> 243 if (!functions) {
> 244 kfree(pctrl->functions);
>
> This will lead to a double free.
>
> 245 return -ENOMEM;
> 246 }
> 247 pctrl->functions = functions;
>
> I'm really concerned about this generally. It's like we can't tell if
> pctrl->functions is a managed allocation or not, and I can't immediately
> see where it is freed when it's unmanaged.
>
> 248
>
> regards,
> dan carpenter
Oh I see. Damn, missed the devm_kzalloc(). But shouldn't we avoid krealloc()
on devm_kzalloc() in general? krealloc() calls kfree() if the reallocation
succeeded and this will break the devres tracking, wouldn't it?
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
next prev parent reply other threads:[~2016-10-12 8:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 8:14 [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails Dan Carpenter
2016-10-12 8:30 ` Johannes Thumshirn [this message]
2016-10-12 8:45 ` Dan Carpenter
2016-10-12 9:44 ` Johannes Thumshirn
2016-10-12 11:19 ` Dan Carpenter
2016-10-12 12:36 ` Johannes Thumshirn
2016-10-12 17:06 ` Dan Carpenter
2016-10-13 13:09 ` Johannes Thumshirn
2016-10-18 12:34 ` Linus Walleij
2016-10-18 14:12 ` Johannes Thumshirn
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=20161012083002.c4tsiuis4suna77h@linux-x5ow.site \
--to=jthumshirn@suse.de \
--cc=dan.carpenter@oracle.com \
--cc=linux-gpio@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).