From: Vlastimil Babka <caster@gentoo.org>
To: "Moore, Robert" <robert.moore@intel.com>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Thomas Renninger <trenn@suse.de>,
collinm@laboiteaprog.com
Subject: Re: PROBLEM: NULL pointer dereference in acpi_ns_check_object_type()
Date: Tue, 03 Jul 2012 11:15:55 +0200 [thread overview]
Message-ID: <4FF2B84B.1060000@gentoo.org> (raw)
In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E346B0252D@ORSMSX101.amr.corp.intel.com>
On 07/02/2012 09:59 PM, Moore, Robert wrote:
> I was able to reproduce the problem here with your ACPI tables.
>
> Will look at your patch, and get back to you.
Thanks.
> You should probably open a bugzilla on this.
Done: bug 44171
https://bugzilla.kernel.org/show_bug.cgi?id=44171
> Thanks,
> Bob
>
>
>> -----Original Message-----
>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>> owner@vger.kernel.org] On Behalf Of Vlastimil Babka
>> Sent: Monday, July 02, 2012 1:45 AM
>> To: linux-acpi@vger.kernel.org
>> Subject: PROBLEM: NULL pointer dereference in
>> acpi_ns_check_object_type()
>>
>> Hello,
>>
>> I've been experiencing kernel panic with NULL pointer dereference in
>> acpi_ns_check_object_type since kernel 3.4 on a MacPro machine.
>>
>> By recompiling as much of ACPI as possible as modules, I was able to
>> get the system running and postpone the error until doing 'modprobe
>> acpi-cpufreq', which now results in oops, not panic. The log is
>> attached as error.log.
>>
>> By bisecting linus tree between 3.3 and 3.4, I found the guilty commit
>> 6a99b1c94d053b3420eaa4a4bc8b2883dd90a2f9
>> "ACPICA: Object repair code: Support to add Package wrappers" [1]
>> However this patch does not directly touch the functions in the stack
>> trace.
>>
>> Next I created a kdump of the oops, and looked around with gdb.
>> - In acpi_ns_check_package(), the null pointer is in the parameter
>> return_object_ptr, which is dereferenced when initializing the variable
>> return_object.
>> - The calling function acpi_ns_check_package_list() is in the 'case
>> ACPI_PTYPE2_COUNT:' part, the passed null pointer is in the
>> sub_elements variable.
>> - Before the switch, sub_elements is initialized like this:
>>
>> sub_elements = sub_package->package.elements
>>
>> interestingly, in the crashdump, sub_elements is null, but
>> sub_package->package.elements is non-null
>>
>> I've added some printk's and verified that the call of status =
>> acpi_ns_check_object_type(data, &sub_package,
>> ACPI_RTYPE_PACKAGE, i);
>>
>> makes sub_package->package.elements become non-null, but sub_elements
>> was already initialized before this call and remains null.
>>
>> The above led me to create the attached patch which simply moves the
>> initialization of sub_elements after the sub_package check. I think
>> it's this check that results in the Integer to Package
>> conversion/wrapping.
>>
>> After this patch, the null pointer dereference is gone, but the debug
>> output of ACPI (acpi.debug_layer=0xffffffff
>> acpi.debug_level=0x00000008) shows that something is probably still
>> wrong:
>>
>> [ 1.353677] nsrepair-0681 [4294967287] ns_wrap_with_package :
>> \_PR_.CPU0._PSD: Wrapped Integer with expected Package object
>> [ 1.353869] nsrepair-0681 [4294967287] ns_wrap_with_package :
>> \_PR_.CPU0._PSD: Wrapped Integer with expected Package object
>> [ 1.354059] ACPI Warning: For \_PR_.CPU0._PSD: Return Sub-Package[0]
>> is too small - found 1 elements, expected 5 (20120320/nspredef-905)
>> [ 1.354253] ACPI: Invalid package argument
>> [ 1.354322] ACPI: Invalid _PSD data
>> ... (the same for other CPUx)
>>
>>
>> In comparison, 3.3 kernel with same acpi debug options shows only stuff
>> like:
>> [ 1.494238] nsrepair-0728 [4294967287] ns_repair_package_list:
>> \_PR_.CPU0._PSD: Repaired incorrectly formed Package
>> [ 1.494449] nsrepair-0728 [4294967287] ns_repair_package_list:
>> \_PR_.CPU2._PSD: Repaired incorrectly formed Package
>> [ 1.494657] nsrepair-0728 [4294967287] ns_repair_package_list:
>> \_PR_.CPU4._PSD: Repaired incorrectly formed Package ... (the same for
>> other CPUx)
>>
>> Since I don't know much about this subsystem, I figured that I should
>> just report my findings at this point. The patched system is usable,
>> but I guess it's not a complete fix.
>>
>> I also attach the output of acpidump. I hope I didn't forget anything
>> important, please ask for more information if needed.
>>
>> Thanks,
>> Vlastimil Babka
>>
>> [1]
>> git.kernel.org/?p=linux/kernel/git/torvalds/linux-
>> 2.6.git;a=commit;h=6a99b1c94d053b3420eaa4a4bc8b2883dd90a2f9
>
> N�����r��y���b�X��ǧv�^�){.n�+����{�i�b�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+��ݢj"��!tml=
>
--
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
prev parent reply other threads:[~2012-07-03 9:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-02 8:45 PROBLEM: NULL pointer dereference in acpi_ns_check_object_type() Vlastimil Babka
2012-07-02 19:59 ` Moore, Robert
2012-07-03 9:15 ` Vlastimil Babka [this message]
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=4FF2B84B.1060000@gentoo.org \
--to=caster@gentoo.org \
--cc=collinm@laboiteaprog.com \
--cc=linux-acpi@vger.kernel.org \
--cc=robert.moore@intel.com \
--cc=trenn@suse.de \
/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.