Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751795AbdFOTxD (ORCPT ); Thu, 15 Jun 2017 15:53:03 -0400 Received: from mga01.intel.com ([192.55.52.88]:10292 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750749AbdFOTxB (ORCPT ); Thu, 15 Jun 2017 15:53:01 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,344,1493708400"; d="scan'208";a="114959858" From: "Moore, Robert" To: Seunghun Han , "Zheng, Lv" , "Wysocki, Rafael J" CC: "linux-acpi@vger.kernel.org" , "devel@acpica.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks Thread-Topic: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks Thread-Index: AQHS5P7GqRelx5FkekiZOKJH9hAMs6ImV6iw Date: Thu, 15 Jun 2017 19:52:59 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37E5C0D49@ORSMSX110.amr.corp.intel.com> References: <1497438490-22268-1-git-send-email-kkamagui@gmail.com> In-Reply-To: <1497438490-22268-1-git-send-email-kkamagui@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v5FJrJbI005456 Content-Length: 6925 Lines: 167 This might be a dumb question, but isn't the system basically hosed once the ACPI subsystem is shutdown? > -----Original Message----- > From: Seunghun Han [mailto:kkamagui@gmail.com] > Sent: Wednesday, June 14, 2017 4:08 AM > To: Zheng, Lv ; Moore, Robert > ; Wysocki, Rafael J > Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux- > kernel@vger.kernel.org; Seunghun Han > Subject: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks > > I'm Seunghun Han, and I work for National Security Research Institute of > South Korea. > > I have been doing a research on ACPI and found an ACPI cache leak in > ACPI early abort cases. > > Boot log of ACPI cache leak is as follows: > [ 0.352414] ACPI: Added _OSI(Module Device) > [ 0.353182] ACPI: Added _OSI(Processor Device) > [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) > [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) > [ 0.356028] ACPI: Unable to start the ACPI Interpreter > [ 0.356799] ACPI Error: Could not remove SCI handler > (20170303/evmisc-281) > [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has > objects > [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W > 4.12.0-rc4-next-20170608+ #10 > [ 0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [ 0.361873] Call Trace: > [ 0.362243] ? dump_stack+0x5c/0x81 > [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 > [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 > [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 > [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b > [ 0.364000] ? acpi_terminate+0xa/0x14 > [ 0.364000] ? acpi_init+0x2af/0x34f > [ 0.364000] ? __class_create+0x4c/0x80 > [ 0.364000] ? video_setup+0x7f/0x7f > [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 > [ 0.364000] ? do_one_initcall+0x4e/0x1a0 > [ 0.364000] ? kernel_init_freeable+0x189/0x20a > [ 0.364000] ? rest_init+0xc0/0xc0 > [ 0.364000] ? kernel_init+0xa/0x100 > [ 0.364000] ? ret_from_fork+0x25/0x30 > > I analyzed this memory leak detailed. I found that “Acpi-State” cache > and “Acpi-Parse” cache were merged because the size of cache objects was > same slab cache size. > > I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked > using SLAB_NEVER_MERGE flag in kmem_cache_create() function. > > Real ACPI cache leak point is as follows: > [ 0.360101] ACPI: Added _OSI(Module Device) > [ 0.360101] ACPI: Added _OSI(Processor Device) > [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) > [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) > [ 0.364016] ACPI: Unable to start the ACPI Interpreter > [ 0.365061] ACPI Error: Could not remove SCI handler > (20170303/evmisc-281) > [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has > objects > [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W > 4.12.0-rc4-next-20170608+ #8 > [ 0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [ 0.372000] Call Trace: > [ 0.372000] ? dump_stack+0x5c/0x81 > [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 > [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 > [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 > [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b > [ 0.372000] ? acpi_terminate+0xa/0x14 > [ 0.372000] ? acpi_init+0x2af/0x34f > [ 0.372000] ? __class_create+0x4c/0x80 > [ 0.372000] ? video_setup+0x7f/0x7f > [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 > [ 0.372000] ? do_one_initcall+0x4e/0x1a0 > [ 0.372000] ? kernel_init_freeable+0x189/0x20a > [ 0.372000] ? rest_init+0xc0/0xc0 > [ 0.372000] ? kernel_init+0xa/0x100 > [ 0.372000] ? ret_from_fork+0x25/0x30 > [ 0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has > objects > [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W > 4.12.0-rc4-next-20170608+ #8 > [ 0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [ 0.392000] Call Trace: > [ 0.392000] ? dump_stack+0x5c/0x81 > [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 > [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 > [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 > [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b > [ 0.392000] ? acpi_terminate+0xa/0x14 > [ 0.392000] ? acpi_init+0x2af/0x34f > [ 0.392000] ? __class_create+0x4c/0x80 > [ 0.392000] ? video_setup+0x7f/0x7f > [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 > [ 0.392000] ? do_one_initcall+0x4e/0x1a0 > [ 0.392000] ? kernel_init_freeable+0x189/0x20a > [ 0.392000] ? rest_init+0xc0/0xc0 > [ 0.392000] ? kernel_init+0xa/0x100 > [ 0.392000] ? ret_from_fork+0x25/0x30 > > When early abort is occurred due to invalid ACPI information, Linux > kernel terminates ACPI by calling acpi_terminate() function. The > function calls > acpi_ut_delete_caches() function to delete local caches > (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, > ps_node_ext_cache). > > But the deletion codes in acpi_ut_delete_caches() function only delete > slab caches using kmem_cache_destroy() function, therefore the cache > objects should be flushed before acpi_ut_delete_caches() function. > > “Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse > function, acpi_ps_parse_loop(). The function should have flush codes to > handle an error state due to invalid AML codes. > > This cache leak has a security threat because an old kernel (<= 4.9) > shows memory locations of kernel functions in stack dump. Some malicious > users could use this information to neutralize kernel ASLR. > > To fix ACPI cache leak for enhancing security, I made a patch which has > flush codes in acpi_ps_parse_loop() function. > > I hope that this patch improves the security of Linux kernel. > > Thank you. > > Signed-off-by: Seunghun Han > --- > drivers/acpi/acpica/psloop.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/acpi/acpica/psloop.c b/drivers/acpi/acpica/psloop.c > index b422400..5d06383 100644 > --- a/drivers/acpi/acpica/psloop.c > +++ b/drivers/acpi/acpica/psloop.c > @@ -658,5 +658,18 @@ acpi_status acpi_ps_parse_loop(struct > acpi_walk_state *walk_state) > } /* while parser_state->Aml */ > > status = acpi_ps_complete_final_op(walk_state, op, status); > + if (ACPI_FAILURE(status)) { > + /* Flush pushed op objects */ > + > + do { > + acpi_ps_pop_scope(&(walk_state->parser_state), &op, > + &walk_state->arg_types, > + &walk_state->arg_count); > + if (op) { > + acpi_ps_complete_this_op(walk_state, op); > + } > + } while (op); > + } > + > return_ACPI_STATUS(status); > } > -- > 2.1.4