From f38dd154ac847dc63c698f933d9a2ccb35190e34 Mon Sep 17 00:00:00 2001 From: Al Stone Date: Mar 08 2018 23:48:44 +0000 Subject: CVE-2017-13694: fix cache leaks in psobjects.c (BZ#1485348) Signed-off-by: Al Stone --- diff --git a/acpica-tools.spec b/acpica-tools.spec index 2a3a3e8..bb6ceb4 100644 --- a/acpica-tools.spec +++ b/acpica-tools.spec @@ -37,6 +37,7 @@ Patch10: simple-64bit.patch Patch11: be-tpm2.patch Patch12: mips-be-fix.patch Patch13: cve-2017-13693.patch +Patch14: cve-2017-13694.patch BuildRequires: bison patchutils flex @@ -100,6 +101,7 @@ gzip -dc %{SOURCE1} | tar -x --strip-components=1 -f - %patch11 -p1 -b .be-tpm2 %patch12 -p1 -b .mips-be-fix %patch13 -p1 -b .cve-2017-13693 +%patch14 -p1 -b .cve-2017-13694 cp -p %{SOURCE2} README.Fedora cp -p %{SOURCE3} iasl.1 @@ -198,6 +200,8 @@ fi - Update to 20180209 source tree, including patch refeshes. Closes BZ#1544048 - CVE-2017-13693: operand cache leak in dsutils.c -- applied github patch to fix the leak. Resolves BZ#1485346. +- CVE-2017-13694: acpi parse and parseext cache leaks in psobjects.c -- applied + github patch to fix the leaks. Resolves BZ#1485348. * Fri Feb 09 2018 Igor Gnatenko - 20180105-3 - Escape macros in %%changelog diff --git a/cve-2017-13694.patch b/cve-2017-13694.patch new file mode 100644 index 0000000..988afba --- /dev/null +++ b/cve-2017-13694.patch @@ -0,0 +1,216 @@ +From 4a0243ecb4c94e2d73510d096c5ea4d0711fc6c0 Mon Sep 17 00:00:00 2001 +From: Seunghun Han +Date: Fri, 23 Jun 2017 14:19:48 +0900 +Subject: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +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 in detail. 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 + +Github-Location: https://github.com/acpica/acpica/pull/278/commits/4a0243ecb4c94e2d73510d096c5ea4d0711fc6c0 + +--- + source/components/parser/psobject.c | 44 ++++++++++++++----------------------- + 1 file changed, 16 insertions(+), 28 deletions(-) + +Index: acpica-unix2-20180209/source/components/parser/psobject.c +=================================================================== +--- acpica-unix2-20180209.orig/source/components/parser/psobject.c ++++ acpica-unix2-20180209/source/components/parser/psobject.c +@@ -680,7 +680,8 @@ AcpiPsCompleteFinalOp ( + ACPI_PARSE_OBJECT *Op, + ACPI_STATUS Status) + { +- ACPI_STATUS Status2; ++ ACPI_STATUS ReturnStatus = AE_OK; ++ BOOLEAN Ascending = TRUE; + + + ACPI_FUNCTION_TRACE_PTR (PsCompleteFinalOp, WalkState); +@@ -697,7 +698,7 @@ AcpiPsCompleteFinalOp ( + { + if (Op) + { +- if (WalkState->AscendingCallback != NULL) ++ if (Ascending && WalkState->AscendingCallback != NULL) + { + WalkState->Op = Op; + WalkState->OpInfo = AcpiPsGetOpcodeInfo (Op->Common.AmlOpcode); +@@ -716,41 +717,28 @@ AcpiPsCompleteFinalOp ( + + if (Status == AE_CTRL_TERMINATE) + { +- Status = AE_OK; +- +- /* Clean up */ +- do +- { +- if (Op) +- { +- Status2 = AcpiPsCompleteThisOp (WalkState, Op); +- if (ACPI_FAILURE (Status2)) +- { +- return_ACPI_STATUS (Status2); +- } +- } +- +- AcpiPsPopScope (&(WalkState->ParserState), &Op, +- &WalkState->ArgTypes, &WalkState->ArgCount); +- +- } while (Op); +- +- return_ACPI_STATUS (Status); ++ Ascending = FALSE; ++ ReturnStatus = AE_CTRL_TERMINATE; + } + + else if (ACPI_FAILURE (Status)) + { + /* First error is most important */ + +- (void) AcpiPsCompleteThisOp (WalkState, Op); +- return_ACPI_STATUS (Status); ++ Ascending = FALSE; ++ ReturnStatus = Status; + } + } + +- Status2 = AcpiPsCompleteThisOp (WalkState, Op); +- if (ACPI_FAILURE (Status2)) ++ Status = AcpiPsCompleteThisOp (WalkState, Op); ++ if (ACPI_FAILURE (Status)) + { +- return_ACPI_STATUS (Status2); ++ Ascending = FALSE; ++ if (ACPI_SUCCESS (ReturnStatus) || ++ ReturnStatus == AE_CTRL_TERMINATE) ++ { ++ ReturnStatus = Status; ++ } + } + } + +@@ -759,5 +747,5 @@ AcpiPsCompleteFinalOp ( + + } while (Op); + +- return_ACPI_STATUS (Status); ++ return_ACPI_STATUS (ReturnStatus); + }