All of lore.kernel.org
 help / color / mirror / Atom feed
* PROBLEM: NULL pointer dereference in acpi_ns_check_object_type()
@ 2012-07-02  8:45 Vlastimil Babka
  2012-07-02 19:59 ` Moore, Robert
  0 siblings, 1 reply; 3+ messages in thread
From: Vlastimil Babka @ 2012-07-02  8:45 UTC (permalink / raw)
  To: linux-acpi

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

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


[-- Attachment #2: error.log --]
[-- Type: text/x-log, Size: 5401 bytes --]

Jun 29 13:50:01 macpro kernel: [  334.597947] nsrepair-0681 [4294967287] ns_wrap_with_package  : \_PR_.CPU0._PSD: Wrapped Integer with expected Package object
Jun 29 13:50:01 macpro kernel: [  334.597951] nsrepair-0681 [4294967287] ns_wrap_with_package  : \_PR_.CPU0._PSD: Wrapped Integer with expected Package object
Jun 29 13:50:01 macpro kernel: [  334.597958] BUG: unable to handle kernel NULL pointer dereference at           (null)
Jun 29 13:50:01 macpro kernel: [  334.597972] IP: [<ffffffff812da10e>] acpi_ns_check_object_type+0x1a/0x1d2
Jun 29 13:50:01 macpro kernel: [  334.597985] PGD 36a625067 PUD 36aa2d067 PMD 0 
Jun 29 13:50:01 macpro kernel: [  334.597995] Oops: 0000 [#1] PREEMPT SMP 
Jun 29 13:50:01 macpro kernel: [  334.598004] CPU 0 
Jun 29 13:50:01 macpro kernel: [  334.598007] Modules linked in: acpi_cpufreq(+) mperf thermal fan battery acpi_ipmi ipmi_msghandler ac coretemp btusb bluetooth ioatdma snd_hda_codec_realtek snd_hda_intel firewire_ohci snd_hda_codec firewire_core i7core_edac i2c_i801 applesmc processor edac_core dca snd_hwdep shpchp rtc_cmos button
Jun 29 13:50:01 macpro kernel: [  334.598075] 
Jun 29 13:50:01 macpro kernel: [  334.598079] Pid: 8683, comm: modprobe Not tainted 3.3.0+ #22 Apple Inc. MacPro4,1/Mac-F221BEC8
Jun 29 13:50:01 macpro kernel: [  334.598091] RIP: 0010:[<ffffffff812da10e>]  [<ffffffff812da10e>] acpi_ns_check_object_type+0x1a/0x1d2
Jun 29 13:50:01 macpro kernel: [  334.598102] RSP: 0018:ffff88036a75bb58  EFLAGS: 00010292
Jun 29 13:50:01 macpro kernel: [  334.598107] RAX: ffff8803717c1ee8 RBX: ffff88036bb79500 RCX: 0000000000000000
Jun 29 13:50:01 macpro kernel: [  334.598113] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88036bb79500
Jun 29 13:50:01 macpro kernel: [  334.598119] RBP: ffff88036a75bbd8 R08: 0000000000000000 R09: 0000000000000000
Jun 29 13:50:01 macpro kernel: [  334.598126] R10: 0000000000000000 R11: 0a7463656a626f20 R12: ffff88036bb79500
Jun 29 13:50:01 macpro kernel: [  334.598132] R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000000
Jun 29 13:50:01 macpro kernel: [  334.598138] FS:  00007fa70776e700(0000) GS:ffff88037fc00000(0000) knlGS:0000000000000000
Jun 29 13:50:01 macpro kernel: [  334.598146] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jun 29 13:50:01 macpro kernel: [  334.598151] CR2: 0000000000000000 CR3: 000000036fa87000 CR4: 00000000000006f0
Jun 29 13:50:01 macpro kernel: [  334.598157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 29 13:50:01 macpro kernel: [  334.598163] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jun 29 13:50:01 macpro kernel: [  334.598173] Process modprobe (pid: 8683, threadinfo ffff88036a75a000, task ffff880369005a40)
Jun 29 13:50:01 macpro kernel: [  334.598180] Stack:
Jun 29 13:50:01 macpro kernel: [  334.598183]  000000000000001e 000000000000001e 7865206874697720 5020646574636570
Jun 29 13:50:01 macpro kernel: [  334.598196]  ffff88036a75bb88 ffffffff812b1c0e ffff88036a75bc18 ffffffff812e695f
Jun 29 13:50:01 macpro kernel: [  334.598208]  ffff88036a75bbb8 ffffffff00000030 ffff88036a75bc38 ffffffff8184632e
Jun 29 13:50:01 macpro kernel: [  334.598221] Call Trace:
Jun 29 13:50:01 macpro kernel: [  334.598227]  [<ffffffff812b1c0e>] ? acpi_os_vprintf+0x2b/0x2d
Jun 29 13:50:01 macpro kernel: [  334.598234]  [<ffffffff812e695f>] ? acpi_debug_print+0xf1/0x100
Jun 29 13:50:01 macpro kernel: [  334.598241]  [<ffffffff812da4b0>] acpi_ns_check_package_list+0x157/0x21a
Jun 29 13:50:01 macpro kernel: [  334.598249]  [<ffffffff812daa7c>] acpi_ns_check_predefined_names+0x3dd/0x48d
Jun 29 13:50:01 macpro kernel: [  334.598256]  [<ffffffff812b2373>] ? acpi_os_signal_semaphore+0x5f/0x6f
Jun 29 13:50:01 macpro kernel: [  334.598263]  [<ffffffff812d8886>] acpi_ns_evaluate+0x32e/0x3b7
Jun 29 13:50:01 macpro kernel: [  334.598271]  [<ffffffff810fd77f>] ? kmem_cache_alloc+0x8f/0xb0
Jun 29 13:50:01 macpro kernel: [  334.598278]  [<ffffffff812dcc06>] acpi_evaluate_object+0x1ec/0x34e
Jun 29 13:50:01 macpro kernel: [  334.598286]  [<ffffffff810d80eb>] ? pcpu_alloc+0x90b/0xa10
Jun 29 13:50:01 macpro kernel: [  334.598295]  [<ffffffffa007157f>] acpi_processor_preregister_performance+0x10e/0x458 [processor]
Jun 29 13:50:01 macpro kernel: [  334.598304]  [<ffffffff810bc9ad>] ? jump_label_module_notify+0x7d/0x200
Jun 29 13:50:01 macpro kernel: [  334.598312]  [<ffffffffa0226000>] ? 0xffffffffa0225fff
Jun 29 13:50:01 macpro kernel: [  334.598319]  [<ffffffffa0226082>] acpi_cpufreq_init+0x82/0xa4 [acpi_cpufreq]
Jun 29 13:50:01 macpro kernel: [  334.598742]  [<ffffffff810001ca>] do_one_initcall+0x3a/0x160
Jun 29 13:50:01 macpro kernel: [  334.599278]  [<ffffffff810855c6>] sys_init_module+0xa16/0x1bc0
Jun 29 13:50:01 macpro kernel: [  334.599811]  [<ffffffff81631be2>] system_call_fastpath+0x16/0x1b
Jun 29 13:50:01 macpro kernel: [  334.600337] Code: 00 e8 c9 c8 00 00 31 c0 5a 5b 41 5c 41 5d 5d c3 90 55 48 89 e5 41 57 41 56 41 89 d6 41 55 41 89 cd 41 54 53 48 89 fb 48 83 ec 58 <4c> 8b 26 4d 85 e4 75 13 48 89 f1 44 89 ea 44 89 f6 e8 08 0a 00 
Jun 29 13:50:01 macpro kernel: [  334.600970] RIP  [<ffffffff812da10e>] acpi_ns_check_object_type+0x1a/0x1d2
Jun 29 13:50:01 macpro kernel: [  334.601559]  RSP <ffff88036a75bb58>
Jun 29 13:50:01 macpro kernel: [  334.602130] CR2: 0000000000000000
Jun 29 13:50:01 macpro kernel: [  334.602838] ---[ end trace 217f289557e3f0cd ]---


[-- Attachment #3: 0001-Hopeful-fix.patch --]
[-- Type: text/x-patch, Size: 1056 bytes --]

>From 0e83f804ecac018e6b1dbeef31478e83a53dd520 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <caster@gentoo.org>
Date: Fri, 29 Jun 2012 15:19:03 +0200
Subject: [PATCH] Hopeful fix.

---
 drivers/acpi/acpica/nspredef.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/acpica/nspredef.c b/drivers/acpi/acpica/nspredef.c
index 23ce096..4a09384 100644
--- a/drivers/acpi/acpica/nspredef.c
+++ b/drivers/acpi/acpica/nspredef.c
@@ -718,7 +718,6 @@ acpi_ns_check_package_list(struct acpi_predefined_data *data,
 	 */
 	for (i = 0; i < count; i++) {
 		sub_package = *elements;
-		sub_elements = sub_package->package.elements;
 		data->parent_package = sub_package;
 
 		/* Each sub-object must be of type Package */
@@ -731,6 +730,7 @@ acpi_ns_check_package_list(struct acpi_predefined_data *data,
 
 		/* Examine the different types of expected sub-packages */
 
+		sub_elements = sub_package->package.elements;
 		data->parent_package = sub_package;
 		switch (package->ret_info.type) {
 		case ACPI_PTYPE2:
-- 
1.7.8.6



[-- Attachment #4: acpidump-3.3.4.gz --]
[-- Type: application/x-gzip, Size: 60630 bytes --]

^ permalink raw reply related	[flat|nested] 3+ messages in thread
* RE: PROBLEM: NULL pointer dereference in acpi_ns_check_object_type()
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Moore, Robert @ 2012-07-02 19:59 UTC (permalink / raw)
  To: Vlastimil Babka, linux-acpi

I was able to reproduce the problem here with your ACPI tables.

Will look at your patch, and get back to you.

You should probably open a bugzilla on this.
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


^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: PROBLEM: NULL pointer dereference in acpi_ns_check_object_type()
  2012-07-02 19:59 ` Moore, Robert
@ 2012-07-03  9:15   ` Vlastimil Babka
  0 siblings, 0 replies; 3+ messages in thread
From: Vlastimil Babka @ 2012-07-03  9:15 UTC (permalink / raw)
  To: Moore, Robert; +Cc: linux-acpi, Thomas Renninger, collinm

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

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-07-03  9:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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.