| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Jun 2017 05:54:58 +0900
From: Seunghun Han <kkamagui@...il.com>
To: "Moore, Robert" <robert.moore@...el.com>
Cc: "Zheng, Lv" <lv.zheng@...el.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"devel@...ica.org" <devel@...ica.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks
Hello, Robert.
My research system are based on virtual machine and Intel NUC machine,
and they are still working despite of ACPI subsystem shutdown.
So, I can find the acpi memory leaks by using "dmesg" command.
Best regards.
2017-06-16 4:52 GMT+09:00 Moore, Robert <robert.moore@...el.com>:
> 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@...il.com]
>> Sent: Wednesday, June 14, 2017 4:08 AM
>> To: Zheng, Lv <lv.zheng@...el.com>; Moore, Robert
>> <robert.moore@...el.com>; Wysocki, Rafael J <rafael.j.wysocki@...el.com>
>> Cc: linux-acpi@...r.kernel.org; devel@...ica.org; linux-
>> kernel@...r.kernel.org; Seunghun Han <kkamagui@...il.com>
>> 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 <kkamagui@...il.com>
>> ---
>> 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
>
Powered by blists - more mailing lists