From patchwork Mon Jul 2 08:45:26 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vlastimil Babka X-Patchwork-Id: 1145911 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 84E2340ABE for ; Mon, 2 Jul 2012 08:45:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932324Ab2GBIpd (ORCPT ); Mon, 2 Jul 2012 04:45:33 -0400 Received: from smtp.gentoo.org ([140.211.166.183]:57337 "EHLO smtp.gentoo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932261Ab2GBIpb (ORCPT ); Mon, 2 Jul 2012 04:45:31 -0400 Received: from [192.168.1.12] (ip-62-24-83-179.net.upcbroadband.cz [62.24.83.179]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: caster) by smtp.gentoo.org (Postfix) with ESMTPSA id D88CB1B402F for ; Mon, 2 Jul 2012 08:45:29 +0000 (UTC) Message-ID: <4FF15FA6.5070109@gentoo.org> Date: Mon, 02 Jul 2012 10:45:26 +0200 From: Vlastimil Babka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120501 Thunderbird/12.0.1 MIME-Version: 1.0 To: linux-acpi@vger.kernel.org Subject: PROBLEM: NULL pointer dereference in acpi_ns_check_object_type() Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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 From 0e83f804ecac018e6b1dbeef31478e83a53dd520 Mon Sep 17 00:00:00 2001 From: Vlastimil Babka 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