From: Bjorn Helgaas <bhelgaas@google.com>
To: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vivek Goyal <vgoyal@redhat.com>,
Vinod Koul <vinod.koul@intel.com>, Cliff Wickman <cpw@sgi.com>,
Jiang Liu <jiang.liu@linux.intel.com>,
Jakub Sitnicki <jsitnicki@gmail.com>,
Thierry Reding <treding@nvidia.com>, Mike Travis <travis@sgi.com>,
linux-kernel@vger.kernel.org,
Grant Likely <grant.likely@linaro.org>
Subject: Re: [PATCH] kernel/resource: Invalid memory access in __release_resource
Date: Mon, 20 Apr 2015 14:28:44 -0500 [thread overview]
Message-ID: <20150420192844.GD20701@google.com> (raw)
In-Reply-To: <1429546972-28400-1-git-send-email-ricardo.ribalda@gmail.com>
[+cc Grant (author of ac80a51e2ce5)]
Hi Ricardo,
On Mon, Apr 20, 2015 at 06:22:52PM +0200, Ricardo Ribalda Delgado wrote:
> When a resource is initialized via of_platform_populate.
> resource->parent is initialized to NULL via kzalloc.
> (of_platform_populate->of_device_alloc->of_address_to_resource)
>
> If of_platform_depopulate is called later, resource->parent is
> accessed (Offset 0x30 of address 0), causing a kernel error.
Interesting; how'd you find this? It looks like the
of_platform_depopulate() code has been this way for a long time, so we
must be doing something new that makes us trip over this now. More
analysis below...
> This patch evaluates resouce->parent before accessing it. If it
> is not initialized, -EACCESS is returned.
>
> Fixes:
> BUG: unable to handle kernel NULL pointer deference at 0000000000000030
> IP: release_resource+0x26/0x90
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> ---
> kernel/resource.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 90552aa..35dc716 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -237,6 +237,9 @@ static int __release_resource(struct resource *old)
> {
> struct resource *tmp, **p;
>
> + if (!old->parent)
> + return -EINVAL;
This path has been fine for a long time without testing for a NULL
pointer, so I suspect this change papers over an issue that would be
better fixed elsewhere.
>From reading drivers/base/platform.c, it looks like the intent is
that platform device users would use these interfaces:
- platform_device_alloc()
- platform_device_add_resources(platform_device *pdev)
pdev->num_resources = num
- platform_device_add(platform_device *pdev)
for (i = 0; i < pdev->num_resources; i++)
insert_resource()
device_add(&pdev->dev)
- platform_device_unregister(platform_device *pdev)
platform_device_del(platform_device *pdev)
for (i = 0; i < pdev->num_resources; i++)
release_resource()
Resources are added by platform_device_add_resources() and inserted
into the resource tree by platform_device_add(). In this usage,
resources are removed from the resource tree by
platform_device_unregister(), and there's no issue with
resource->parent being NULL.
OF uses platform_device_alloc() and platform_device_unregister(), but
not platform_device_add(). It doesn't call insert_resource(), and that
breaks the platform_device_unregister() assumption that the resources
are in the resource tree:
- of_platform_populate()
...
of_device_alloc()
pdev = platform_device_alloc()
# set pdev->resource, similar to platform_device_add_resources()
of_device_add(platform_device *pdev)
# similar to platform_device_add(), but note there's no
# insert_resource() in this path
device_add(&pdev->dev)
- of_platform_depopulate()
of_platform_device_destroy()
platform_device_unregister(platform_device *pdev)
platform_device_del(platform_device *pdev)
for (i = 0; i < pdev->num_resources; i++)
release_resource()
I cc'd Grant because ac80a51e2ce5 ("of/device: populate
platform_device (of_device) resource table on allocation") added the
pdev->resource management in of_device_alloc(), so maybe he has more
insight into this.
> p = &old->parent->child;
> for (;;) {
> tmp = *p;
> --
> 2.1.4
>
next prev parent reply other threads:[~2015-04-20 19:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-20 16:22 [PATCH] kernel/resource: Invalid memory access in __release_resource Ricardo Ribalda Delgado
2015-04-20 19:28 ` Bjorn Helgaas [this message]
2015-04-20 20:24 ` Ricardo Ribalda Delgado
2015-04-20 20:36 ` Bjorn Helgaas
2015-04-20 20:49 ` Ricardo Ribalda Delgado
2015-04-21 6:59 ` Thierry Reding
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=20150420192844.GD20701@google.com \
--to=bhelgaas@google.com \
--cc=akpm@linux-foundation.org \
--cc=cpw@sgi.com \
--cc=grant.likely@linaro.org \
--cc=jiang.liu@linux.intel.com \
--cc=jsitnicki@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ricardo.ribalda@gmail.com \
--cc=travis@sgi.com \
--cc=treding@nvidia.com \
--cc=vgoyal@redhat.com \
--cc=vinod.koul@intel.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.