diff mbox

ACPI / PNP: Do not crash due to stale pointer use during system resume

Message ID 1829835.4TBEQGhjkq@vostro.rjw.lan (mailing list archive)
State Accepted, archived
Headers show

Commit Message

Rafael Wysocki Nov. 29, 2012, 11:10 p.m. UTC
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

During resume from system suspend the 'data' field of
struct pnp_dev in pnpacpi_set_resources() may be a stale pointer,
due to removal of the associated ACPI device node object in the
previous suspend-resume cycle.  This happens, for example, if a
dockable machine is booted in the docking station and then suspended
and resumed and suspended again.  If that happens,
pnpacpi_build_resource_template() called from pnpacpi_set_resources()
attempts to use that pointer and crashes.

However, pnpacpi_set_resources() actually checks the device's ACPI
handle, attempts to find the ACPI device node object attached to it
and returns an error code if that fails, so in fact it knows what the
correct value of dev->data should be.  Use this observation to update
dev->data with the correct value if necessary and dump a call trace
if that's the case (once).

We still need to fix the root cause of this issue, but preventing
systems from crashing because of it is an improvement too.

Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=51071
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/pnp/pnpacpi/core.c |    3 +++
 2 files changed, 6 insertions(+), 1 deletion(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Shuah Khan Nov. 29, 2012, 11:25 p.m. UTC | #1
On Thu, Nov 29, 2012 at 4:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> During resume from system suspend the 'data' field of
> struct pnp_dev in pnpacpi_set_resources() may be a stale pointer,
> due to removal of the associated ACPI device node object in the
> previous suspend-resume cycle.  This happens, for example, if a
> dockable machine is booted in the docking station and then suspended
> and resumed and suspended again.  If that happens,
> pnpacpi_build_resource_template() called from pnpacpi_set_resources()
> attempts to use that pointer and crashes.
>
> However, pnpacpi_set_resources() actually checks the device's ACPI
> handle, attempts to find the ACPI device node object attached to it
> and returns an error code if that fails, so in fact it knows what the
> correct value of dev->data should be.  Use this observation to update
> dev->data with the correct value if necessary and dump a call trace
> if that's the case (once).
>
> We still need to fix the root cause of this issue, but preventing
> systems from crashing because of it is an improvement too.
>
> Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=51071
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Any reason why this shouldn't go into stable releases?

-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Shuah Khan Nov. 29, 2012, 11:50 p.m. UTC | #2
On Thu, Nov 29, 2012 at 4:51 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday, November 29, 2012 04:25:20 PM Shuah Khan wrote:
>> On Thu, Nov 29, 2012 at 4:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> >
>> > During resume from system suspend the 'data' field of
>> > struct pnp_dev in pnpacpi_set_resources() may be a stale pointer,
>> > due to removal of the associated ACPI device node object in the
>> > previous suspend-resume cycle.  This happens, for example, if a
>> > dockable machine is booted in the docking station and then suspended
>> > and resumed and suspended again.  If that happens,
>> > pnpacpi_build_resource_template() called from pnpacpi_set_resources()
>> > attempts to use that pointer and crashes.
>> >
>> > However, pnpacpi_set_resources() actually checks the device's ACPI
>> > handle, attempts to find the ACPI device node object attached to it
>> > and returns an error code if that fails, so in fact it knows what the
>> > correct value of dev->data should be.  Use this observation to update
>> > dev->data with the correct value if necessary and dump a call trace
>> > if that's the case (once).
>> >
>> > We still need to fix the root cause of this issue, but preventing
>> > systems from crashing because of it is an improvement too.
>> >
>> > Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
>> > References: https://bugzilla.kernel.org/show_bug.cgi?id=51071
>> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> Any reason why this shouldn't go into stable releases?
>
> Yes, it can go to -stable.  This is just a patch, not a git commit.  I can
> still add the "stable" tag to it when it goes to git. :-)
>

Good. This patch applies just fine to 3.0.x, 3.4.x and 3.6.x for what
its worth. That's how far I have gotten so far and getting ready to do
compile tests on these.

-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael Wysocki Nov. 29, 2012, 11:51 p.m. UTC | #3
On Thursday, November 29, 2012 04:25:20 PM Shuah Khan wrote:
> On Thu, Nov 29, 2012 at 4:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > During resume from system suspend the 'data' field of
> > struct pnp_dev in pnpacpi_set_resources() may be a stale pointer,
> > due to removal of the associated ACPI device node object in the
> > previous suspend-resume cycle.  This happens, for example, if a
> > dockable machine is booted in the docking station and then suspended
> > and resumed and suspended again.  If that happens,
> > pnpacpi_build_resource_template() called from pnpacpi_set_resources()
> > attempts to use that pointer and crashes.
> >
> > However, pnpacpi_set_resources() actually checks the device's ACPI
> > handle, attempts to find the ACPI device node object attached to it
> > and returns an error code if that fails, so in fact it knows what the
> > correct value of dev->data should be.  Use this observation to update
> > dev->data with the correct value if necessary and dump a call trace
> > if that's the case (once).
> >
> > We still need to fix the root cause of this issue, but preventing
> > systems from crashing because of it is an improvement too.
> >
> > Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=51071
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Any reason why this shouldn't go into stable releases?

Yes, it can go to -stable.  This is just a patch, not a git commit.  I can
still add the "stable" tag to it when it goes to git. :-)

Thanks,
Rafael
diff mbox

Patch

Index: linux/drivers/pnp/pnpacpi/core.c
===================================================================
--- linux.orig/drivers/pnp/pnpacpi/core.c
+++ linux/drivers/pnp/pnpacpi/core.c
@@ -95,6 +95,9 @@  static int pnpacpi_set_resources(struct
 		return -ENODEV;
 	}
 
+	if (WARN_ON_ONCE(acpi_dev != dev->data))
+		dev->data = acpi_dev;
+
 	ret = pnpacpi_build_resource_template(dev, &buffer);
 	if (ret)
 		return ret;