public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* memory leak and other oddness in pinctrl-mvebu.c
@ 2013-03-08 15:58 David Woodhouse
  2013-03-09  8:49 ` Sebastian Hesselbarth
  0 siblings, 1 reply; 21+ messages in thread
From: David Woodhouse @ 2013-03-08 15:58 UTC (permalink / raw)
  To: Sebastian Hesselbarth
  Cc: Thomas Petazzoni, Stephen Warren, Jason Cooper, linux-kernel

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

I'm just looking through the kernel for krealloc() abuse, and the
'interesting' code in mvebu_pinctrl_build_functions() came to my
attention.

First it allocates an array 'funcs' as follows:
	/* we allocate functions for number of pins and hope
	 * there are less unique functions than pins available */
	funcs = devm_kzalloc(&pdev->dev, pctl->desc.npins *
			     sizeof(struct mvebu_pinctrl_function), GFP_KERNEL);

(note: s/less/fewer/ in the comment).

Then it populates the array, seemly trusting to its "hope" and just
going off the end of the array if there are more unique functions than
pins?

And then finally it reallocates the array to the correct size:

	/* with the number of unique functions and it's groups known,
	   reallocate functions and assign group names */
	funcs = krealloc(funcs, num * sizeof(struct mvebu_pinctrl_function),
			 GFP_KERNEL);

(note: s/it's/its/)

So... if krealloc fails, we *leak* the originally-allocated 'funcs'.
Except actually we don't because it was allocated with devm_kzalloc() so
that's OK.

If krealloc *succeeds* then I think we should get a double-free because
it doesn't free the old 'funcs' via devm_kfree() so when the device is
eventually released, won't devres_release_all() free it again?

I'm not entirely sure what that krealloc is *for*, anyway. Apart from
retrospectively reallocating the array to the size that we've already
*scribbled* over? Some kind of request for forgiveness, perhaps?

We should probably make the standard kfree() (and hence krealloc())
actually fail when handed pointers which were allocated with
devm_kzalloc()?

This completely untested patch attempts to fix it by counting the
maximum number of functions in advance, then allocating the array at
that size. In practice it may overallocate if there are name collisions
and _add_function() returns -EEXIST. Is that something we really need to
lose sleep over?

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index c689c04..5f9ece6 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -500,13 +500,25 @@ static int mvebu_pinctrl_build_functions(struct platform_device *pdev,
 	int num = 0;
 	int n, s;
 
-	/* we allocate functions for number of pins and hope
-	 * there are less unique functions than pins available */
-	funcs = devm_kzalloc(&pdev->dev, pctl->desc.npins *
+	/* Count the number of functions prior to allocating 'funcs' array */
+	for (n = 0; n < pctl->num_groups; n++) {
+		struct mvebu_pinctrl_group *grp = &pctl->groups[n];
+		for (s = 0; s < grp->num_settings; s++) {
+			/* skip unsupported settings on this variant */
+			if (pctl->variant &&
+			    !(pctl->variant & grp->settings[s].variant))
+				continue;
+
+			num++;
+		}
+	}
+
+	funcs = devm_kzalloc(&pdev->dev, num *
 			     sizeof(struct mvebu_pinctrl_function), GFP_KERNEL);
 	if (!funcs)
 		return -ENOMEM;
 
+	num = 0;
 	for (n = 0; n < pctl->num_groups; n++) {
 		struct mvebu_pinctrl_group *grp = &pctl->groups[n];
 		for (s = 0; s < grp->num_settings; s++) {
@@ -523,13 +535,6 @@ static int mvebu_pinctrl_build_functions(struct platform_device *pdev,
 		}
 	}
 
-	/* with the number of unique functions and it's groups known,
-	   reallocate functions and assign group names */
-	funcs = krealloc(funcs, num * sizeof(struct mvebu_pinctrl_function),
-			 GFP_KERNEL);
-	if (!funcs)
-		return -ENOMEM;
-
 	pctl->num_functions = num;
 	pctl->functions = funcs;
 

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply related	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2013-03-28 12:07 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-08 15:58 memory leak and other oddness in pinctrl-mvebu.c David Woodhouse
2013-03-09  8:49 ` Sebastian Hesselbarth
2013-03-09 19:02   ` David Woodhouse
2013-03-09 19:46     ` Sebastian Hesselbarth
2013-03-09 22:53     ` Jason Cooper
2013-03-09 23:39       ` David Woodhouse
2013-03-10  0:06         ` Jason Cooper
2013-03-13 16:59           ` Linus Walleij
2013-03-13 17:35         ` [PATCH] pinctrl: mvebu: prevent walking off the end of group array Jason Cooper
2013-03-13 17:47           ` Linus Walleij
2013-03-13 17:50             ` Jason Cooper
2013-03-13 18:40               ` Linus Walleij
2013-03-13 17:48           ` Sebastian Hesselbarth
2013-03-13 17:48         ` [PATCH V2] " Jason Cooper
2013-03-14 10:29           ` David Woodhouse
2013-03-16 11:44           ` [PATCH v3] " Sebastian Hesselbarth
2013-03-22 16:39             ` Jason Cooper
2013-03-27 22:06             ` Linus Walleij
2013-03-27 22:11               ` Woodhouse, David
2013-03-27 22:34                 ` Linus Walleij
2013-03-28 11:08                   ` Jason Cooper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox