Skip to content

Commit 8829e70

Browse files
committed
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 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 complete all ops using acpi_ps_complete_final_op() when an error occurs due to invalid AML codes. However, the current implementation of acpi_ps_complete_final_op() does not complete all ops when it meets some errors and this cause cache leak. 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 to complete all ops unconditionally for acpi_ps_complete_final_op() function. I hope that this patch improves the security of Linux kernel. Thank you. Signed-off-by: Seunghun Han <kkamagui@gmail.com>
1 parent 2058b3b commit 8829e70

File tree

1 file changed

+16
-28
lines changed

1 file changed

+16
-28
lines changed

source/components/parser/psobject.c

Lines changed: 16 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -768,7 +768,8 @@ AcpiPsCompleteFinalOp (
768768
ACPI_PARSE_OBJECT *Op,
769769
ACPI_STATUS Status)
770770
{
771-
ACPI_STATUS Status2;
771+
ACPI_STATUS ReturnStatus = Status;
772+
BOOLEAN Ascending = TRUE;
772773

773774

774775
ACPI_FUNCTION_TRACE_PTR (PsCompleteFinalOp, WalkState);
@@ -785,7 +786,7 @@ AcpiPsCompleteFinalOp (
785786
{
786787
if (Op)
787788
{
788-
if (WalkState->AscendingCallback != NULL)
789+
if (Ascending && WalkState->AscendingCallback != NULL)
789790
{
790791
WalkState->Op = Op;
791792
WalkState->OpInfo = AcpiPsGetOpcodeInfo (Op->Common.AmlOpcode);
@@ -804,41 +805,28 @@ AcpiPsCompleteFinalOp (
804805

805806
if (Status == AE_CTRL_TERMINATE)
806807
{
807-
Status = AE_OK;
808-
809-
/* Clean up */
810-
do
811-
{
812-
if (Op)
813-
{
814-
Status2 = AcpiPsCompleteThisOp (WalkState, Op);
815-
if (ACPI_FAILURE (Status2))
816-
{
817-
return_ACPI_STATUS (Status2);
818-
}
819-
}
820-
821-
AcpiPsPopScope (&(WalkState->ParserState), &Op,
822-
&WalkState->ArgTypes, &WalkState->ArgCount);
823-
824-
} while (Op);
825-
826-
return_ACPI_STATUS (Status);
808+
Ascending = FALSE;
809+
ReturnStatus = AE_CTRL_TERMINATE;
827810
}
828811

829812
else if (ACPI_FAILURE (Status))
830813
{
831814
/* First error is most important */
832815

833-
(void) AcpiPsCompleteThisOp (WalkState, Op);
834-
return_ACPI_STATUS (Status);
816+
Ascending = FALSE;
817+
ReturnStatus = Status;
835818
}
836819
}
837820

838-
Status2 = AcpiPsCompleteThisOp (WalkState, Op);
839-
if (ACPI_FAILURE (Status2))
821+
Status = AcpiPsCompleteThisOp (WalkState, Op);
822+
if (ACPI_FAILURE (Status))
840823
{
841-
return_ACPI_STATUS (Status2);
824+
Ascending = FALSE;
825+
if (ACPI_SUCCESS (ReturnStatus) ||
826+
ReturnStatus == AE_CTRL_TERMINATE)
827+
{
828+
ReturnStatus = Status;
829+
}
842830
}
843831
}
844832

@@ -847,5 +835,5 @@ AcpiPsCompleteFinalOp (
847835

848836
} while (Op);
849837

850-
return_ACPI_STATUS (Status);
838+
return_ACPI_STATUS (ReturnStatus);
851839
}

0 commit comments

Comments
 (0)