[PATCH V2] acpi: acpica: fix acpi operand cache leak in dswstate.c

[Seunghun Han]

I found an ACPI cache leak in ACPI early termination and boot continuing case.

When early termination is occurred due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.

Boot log of ACPI operand cache leak is as follows:
>[0.585957] ACPI: Added _OSI(Module Device)
>[0.587218] ACPI: Added _OSI(Processor Device)
>[0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[0.591534] ACPI Error: Illegal I/O port address/length above 64K: 
>C806E0004002/0x2 (20170303/hwvalid-155)
>[0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events 
>(20170303/evevent-88)
>[0.597858] ACPI: Unable to start the ACPI Interpreter
>[0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
>VirtualBox 12/01/2006
>[0.609177] Call Trace:
>[0.610063]  ? dump_stack+0x5c/0x81
>[0.68]  ? kmem_cache_destroy+0x1aa/0x1c0
>[0.612632]  ? acpi_sleep_proc_init+0x27/0x27
>[0.613906]  ? acpi_os_delete_cache+0xa/0x10
>[0.617986]  ? acpi_ut_delete_caches+0x3f/0x7b
>[0.619293]  ? acpi_terminate+0xa/0x14
>[0.620394]  ? acpi_init+0x2af/0x34f
>[0.621616]  ? __class_create+0x4c/0x80
>[0.623412]  ? video_setup+0x7f/0x7f
>[0.624585]  ? acpi_sleep_proc_init+0x27/0x27
>[0.625861]  ? do_one_initcall+0x4e/0x1a0
>[0.627513]  ? kernel_init_freeable+0x19e/0x21f
>[0.628972]  ? rest_init+0x80/0x80
>[0.630043]  ? kernel_init+0xa/0x100
>[0.631084]  ? ret_from_fork+0x25/0x30
>[0.633343] vgaarb: loaded
>[0.635036] EDAC MC: Ver: 3.0.0
>[0.638601] PCI: Probing PCI hardware
>[0.639833] PCI host bridge to bus :00
>[0.641031] pci_bus :00: root bus resource [io  0x-0x]
> ... Continue to boot and log is omitted ...

I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.

This cache leak causes 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.

I made a patch to fix ACPI operand cache leak.

Signed-off-by: Seunghun Han 
---
Changes since V1: move stack_top into loop and change loop condition.

 drivers/acpi/acpica/dswstate.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/dswstate.c b/drivers/acpi/acpica/dswstate.c
index da111a1..882a3d1 100644
--- a/drivers/acpi/acpica/dswstate.c
+++ b/drivers/acpi/acpica/dswstate.c
@@ -402,7 +402,8 @@ void
 acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
 struct acpi_walk_state *walk_state)
 {
-   s32 i;
+   u32 i;
+   s32 stack_top;
union acpi_operand_object *obj_desc;
 
ACPI_FUNCTION_NAME(ds_obj_stack_pop_and_delete);
@@ -411,7 +412,11 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
return;
}
 
-   for (i = (s32)pop_count - 1; i >= 0; i--) {
+   /* Calculate curruent top of the stack */
+
+   stack_top = (s32)walk_state->num_operands + walk_state->operand_index - 
1;
+
+   for (i = 0; i < pop_count ; i++) {
if (walk_state->num_operands == 0) {
return;
}
@@ -419,11 +424,12 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
/* Pop the stack and delete an object if present in this stack 
entry */
 
walk_state->num_operands--;
-   obj_desc = walk_state->operands[i];
+   obj_desc = walk_state->operands[stack_top];
if (obj_desc) {
-   acpi_ut_remove_reference(walk_state->operands[i]);
-   walk_state->operands[i] = NULL;
+   
acpi_ut_remove_reference(walk_state->operands[stack_top]);
+   walk_state->operands[stack_top] = NULL;
}
+   stack_top--;
}
 
ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Count=%X State=%p #Ops=%X\n",
-- 
2.1.4

[PATCH V2] acpi: acpica: fix acpi operand cache leak in dswstate.c

[Seunghun Han]

I found an ACPI cache leak in ACPI early termination and boot continuing case.

When early termination is occurred due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.

Boot log of ACPI operand cache leak is as follows:
>[0.585957] ACPI: Added _OSI(Module Device)
>[0.587218] ACPI: Added _OSI(Processor Device)
>[0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[0.591534] ACPI Error: Illegal I/O port address/length above 64K: 
>C806E0004002/0x2 (20170303/hwvalid-155)
>[0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events 
>(20170303/evevent-88)
>[0.597858] ACPI: Unable to start the ACPI Interpreter
>[0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
>VirtualBox 12/01/2006
>[0.609177] Call Trace:
>[0.610063]  ? dump_stack+0x5c/0x81
>[0.68]  ? kmem_cache_destroy+0x1aa/0x1c0
>[0.612632]  ? acpi_sleep_proc_init+0x27/0x27
>[0.613906]  ? acpi_os_delete_cache+0xa/0x10
>[0.617986]  ? acpi_ut_delete_caches+0x3f/0x7b
>[0.619293]  ? acpi_terminate+0xa/0x14
>[0.620394]  ? acpi_init+0x2af/0x34f
>[0.621616]  ? __class_create+0x4c/0x80
>[0.623412]  ? video_setup+0x7f/0x7f
>[0.624585]  ? acpi_sleep_proc_init+0x27/0x27
>[0.625861]  ? do_one_initcall+0x4e/0x1a0
>[0.627513]  ? kernel_init_freeable+0x19e/0x21f
>[0.628972]  ? rest_init+0x80/0x80
>[0.630043]  ? kernel_init+0xa/0x100
>[0.631084]  ? ret_from_fork+0x25/0x30
>[0.633343] vgaarb: loaded
>[0.635036] EDAC MC: Ver: 3.0.0
>[0.638601] PCI: Probing PCI hardware
>[0.639833] PCI host bridge to bus :00
>[0.641031] pci_bus :00: root bus resource [io  0x-0x]
> ... Continue to boot and log is omitted ...

I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.

This cache leak causes 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.

I made a patch to fix ACPI operand cache leak.

Signed-off-by: Seunghun Han 
---
Changes since V1: move stack_top into loop and change loop condition.

 drivers/acpi/acpica/dswstate.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/dswstate.c b/drivers/acpi/acpica/dswstate.c
index da111a1..882a3d1 100644
--- a/drivers/acpi/acpica/dswstate.c
+++ b/drivers/acpi/acpica/dswstate.c
@@ -402,7 +402,8 @@ void
 acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
 struct acpi_walk_state *walk_state)
 {
-   s32 i;
+   u32 i;
+   s32 stack_top;
union acpi_operand_object *obj_desc;
 
ACPI_FUNCTION_NAME(ds_obj_stack_pop_and_delete);
@@ -411,7 +412,11 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
return;
}
 
-   for (i = (s32)pop_count - 1; i >= 0; i--) {
+   /* Calculate curruent top of the stack */
+
+   stack_top = (s32)walk_state->num_operands + walk_state->operand_index - 
1;
+
+   for (i = 0; i < pop_count ; i++) {
if (walk_state->num_operands == 0) {
return;
}
@@ -419,11 +424,12 @@ acpi_ds_obj_stack_pop_and_delete(u32 pop_count,
/* Pop the stack and delete an object if present in this stack 
entry */
 
walk_state->num_operands--;
-   obj_desc = walk_state->operands[i];
+   obj_desc = walk_state->operands[stack_top];
if (obj_desc) {
-   acpi_ut_remove_reference(walk_state->operands[i]);
-   walk_state->operands[i] = NULL;
+   
acpi_ut_remove_reference(walk_state->operands[stack_top]);
+   walk_state->operands[stack_top] = NULL;
}
+   stack_top--;
}
 
ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Count=%X State=%p #Ops=%X\n",
-- 
2.1.4

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, 

> From: Seunghun Han [mailto:kkama...@gmail.com]
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> Hello, Lv and Rafael.
> 
> I checked that my patch was merged to ACPICA project.
> Thank you for your notice.
> 
> I added an analysis report which has the root cause of this problem below.
> 
> 2017-02-27 11:45 GMT+09:00 Zheng, Lv <lv.zh...@intel.com>:
> > Hi, Rafael
> >
> >> From: linux-acpi-ow...@vger.kernel.org 
> >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of
> Rafael J.
> >> Wysocki
> >> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>
> >> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
> >> > Hi, Rafael.
> >> >
> >> > I agree with you and I added my opinion below.
> >> >
> >> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >> >>> Hi, Rafeal.
> >> >>>
> >> >>> I added my opinion below.
> >> >>>
> >> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >> >>> >> Hi, Rafael.
> >> >>> >>
> >> >>> >> I added my opinion below.
> >> >>> >>
> >> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> >>> >> >> Hi, Lv Zheng.
> >> >>> >> >>
> >> >>> >> >> I added my handcrafted ACPI table under your request, because
> >> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >> >>> >> >>
> >> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> >> >>> >> >> > Hello,
> >> >>> >> >> >
> >> >>> >> >> > I attached the test results below,
> >> >>> >> >> >
> >> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >> >>> >> >> > <r...@rjwysocki.net>:
> >> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >>> >> >> >>> Hi,
> >> >>> >> >> >>>
> >> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> >> Behalf Of Seunghun
> >> >>> >> >> >>> > Han
> >> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache 
> >> >>> >> >> >>> > leak
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security 
> >> >>> >> >> >>> > Research Institute of
> >> >>> >> >> >>> > South Korea.
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > I have been doing a research on ACPI and making a 
> >> >>> >> >> >>> > handcrafted ACPI table
> >> >>> >> >> >>> > for my research.
> >> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in 
> >> >>> >> >> >>> > Linux kernel while boot
> >> >>> >> >> >>> > process, and Linux kernel goes well without critical 
> >> >>> >> >> >>> > problems.
> >> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
> >> >>> >> >> >>> > abort cases.
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >>> >> >> >>> > >

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, 

> From: Seunghun Han [mailto:kkama...@gmail.com]
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> Hello, Lv and Rafael.
> 
> I checked that my patch was merged to ACPICA project.
> Thank you for your notice.
> 
> I added an analysis report which has the root cause of this problem below.
> 
> 2017-02-27 11:45 GMT+09:00 Zheng, Lv :
> > Hi, Rafael
> >
> >> From: linux-acpi-ow...@vger.kernel.org 
> >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of
> Rafael J.
> >> Wysocki
> >> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>
> >> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> >> > Hi, Rafael.
> >> >
> >> > I agree with you and I added my opinion below.
> >> >
> >> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> >> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >> >>> Hi, Rafeal.
> >> >>>
> >> >>> I added my opinion below.
> >> >>>
> >> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> >> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >> >>> >> Hi, Rafael.
> >> >>> >>
> >> >>> >> I added my opinion below.
> >> >>> >>
> >> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> >>> >> >> Hi, Lv Zheng.
> >> >>> >> >>
> >> >>> >> >> I added my handcrafted ACPI table under your request, because
> >> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >> >>> >> >>
> >> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >> >>> >> >> > Hello,
> >> >>> >> >> >
> >> >>> >> >> > I attached the test results below,
> >> >>> >> >> >
> >> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >> >>> >> >> > :
> >> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >>> >> >> >>> Hi,
> >> >>> >> >> >>>
> >> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> >> Behalf Of Seunghun
> >> >>> >> >> >>> > Han
> >> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache 
> >> >>> >> >> >>> > leak
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security 
> >> >>> >> >> >>> > Research Institute of
> >> >>> >> >> >>> > South Korea.
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > I have been doing a research on ACPI and making a 
> >> >>> >> >> >>> > handcrafted ACPI table
> >> >>> >> >> >>> > for my research.
> >> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in 
> >> >>> >> >> >>> > Linux kernel while boot
> >> >>> >> >> >>> > process, and Linux kernel goes well without critical 
> >> >>> >> >> >>> > problems.
> >> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
> >> >>> >> >> >>> > abort cases.
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hello, Lv and Rafael.

I checked that my patch was merged to ACPICA project.
Thank you for your notice.

I added an analysis report which has the root cause of this problem below.

2017-02-27 11:45 GMT+09:00 Zheng, Lv <lv.zh...@intel.com>:
> Hi, Rafael
>
>> From: linux-acpi-ow...@vger.kernel.org 
>> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
>> Wysocki
>> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>
>> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
>> > Hi, Rafael.
>> >
>> > I agree with you and I added my opinion below.
>> >
>> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> >>> Hi, Rafeal.
>> >>>
>> >>> I added my opinion below.
>> >>>
>> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> >>> >> Hi, Rafael.
>> >>> >>
>> >>> >> I added my opinion below.
>> >>> >>
>> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >>> >> >> Hi, Lv Zheng.
>> >>> >> >>
>> >>> >> >> I added my handcrafted ACPI table under your request, because
>> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>> >> >>
>> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
>> >>> >> >> > Hello,
>> >>> >> >> >
>> >>> >> >> > I attached the test results below,
>> >>> >> >> >
>> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
>> >>> >> >> > <r...@rjwysocki.net>:
>> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >>> >> >> >>> Hi,
>> >>> >> >> >>>
>> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
>> Behalf Of Seunghun
>> >>> >> >> >>> > Han
>> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >>> >> >> >>> >
>> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >>> >> >> >>> > Institute of
>> >>> >> >> >>> > South Korea.
>> >>> >> >> >>> >
>> >>> >> >> >>> > I have been doing a research on ACPI and making a 
>> >>> >> >> >>> > handcrafted ACPI table
>> >>> >> >> >>> > for my research.
>> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>> >>> >> >> >>> > kernel while boot
>> >>> >> >> >>> > process, and Linux kernel goes well without critical 
>> >>> >> >> >>> > problems.
>> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
>> >>> >> >> >>> > abort cases.
>> >>> >> >> >>> >
>> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >>> >> >> &g

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hello, Lv and Rafael.

I checked that my patch was merged to ACPICA project.
Thank you for your notice.

I added an analysis report which has the root cause of this problem below.

2017-02-27 11:45 GMT+09:00 Zheng, Lv :
> Hi, Rafael
>
>> From: linux-acpi-ow...@vger.kernel.org 
>> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
>> Wysocki
>> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>
>> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
>> > Hi, Rafael.
>> >
>> > I agree with you and I added my opinion below.
>> >
>> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
>> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> >>> Hi, Rafeal.
>> >>>
>> >>> I added my opinion below.
>> >>>
>> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
>> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> >>> >> Hi, Rafael.
>> >>> >>
>> >>> >> I added my opinion below.
>> >>> >>
>> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >>> >> >> Hi, Lv Zheng.
>> >>> >> >>
>> >>> >> >> I added my handcrafted ACPI table under your request, because
>> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>> >> >>
>> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> >>> >> >> > Hello,
>> >>> >> >> >
>> >>> >> >> > I attached the test results below,
>> >>> >> >> >
>> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
>> >>> >> >> > :
>> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >>> >> >> >>> Hi,
>> >>> >> >> >>>
>> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
>> Behalf Of Seunghun
>> >>> >> >> >>> > Han
>> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >>> >> >> >>> >
>> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >>> >> >> >>> > Institute of
>> >>> >> >> >>> > South Korea.
>> >>> >> >> >>> >
>> >>> >> >> >>> > I have been doing a research on ACPI and making a 
>> >>> >> >> >>> > handcrafted ACPI table
>> >>> >> >> >>> > for my research.
>> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>> >>> >> >> >>> > kernel while boot
>> >>> >> >> >>> > process, and Linux kernel goes well without critical 
>> >>> >> >> >>> > problems.
>> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
>> >>> >> >> >>> > abort cases.
>> >>> >> >> >>> >
>> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>> >>> >> >> >>> > >install System Control
>> Interrupt

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Monday, February 27, 2017 02:45:50 AM Zheng, Lv wrote:
> Hi, Rafael
> 
> > From: linux-acpi-ow...@vger.kernel.org 
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> > Wysocki
> > Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> > 
> > On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
> > > Hi, Rafael.
> > >
> > > I agree with you and I added my opinion below.
> > >
> > > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> > >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> > >>> Hi, Rafeal.
> > >>>
> > >>> I added my opinion below.
> > >>>
> > >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> > >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> > >>> >> Hi, Rafael.
> > >>> >>
> > >>> >> I added my opinion below.
> > >>> >>
> > >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> > >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> > >>> >> >> Hi, Lv Zheng.
> > >>> >> >>
> > >>> >> >> I added my handcrafted ACPI table under your request, because
> > >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> > >>> >> >>
> > >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> > >>> >> >> > Hello,
> > >>> >> >> >
> > >>> >> >> > I attached the test results below,
> > >>> >> >> >
> > >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> > >>> >> >> > <r...@rjwysocki.net>:
> > >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> > >>> >> >> >>> Hi,
> > >>> >> >> >>>
> > >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> > >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> > Behalf Of Seunghun
> > >>> >> >> >>> > Han
> > >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache 
> > >>> >> >> >>> > leak
> > >>> >> >> >>> >
> > >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> > >>> >> >> >>> > Institute of
> > >>> >> >> >>> > South Korea.
> > >>> >> >> >>> >
> > >>> >> >> >>> > I have been doing a research on ACPI and making a 
> > >>> >> >> >>> > handcrafted ACPI table
> > >>> >> >> >>> > for my research.
> > >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> > >>> >> >> >>> > kernel while boot
> > >>> >> >> >>> > process, and Linux kernel goes well without critical 
> > >>> >> >> >>> > problems.
> > >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
> > >>> >> >> >>> > abort cases.
> > >>> >> >> >>> >
> > >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> > >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> > >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> > >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> > >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator 
> > >>> >> >> >>> > >Device)
> > >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> > >

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Monday, February 27, 2017 02:45:50 AM Zheng, Lv wrote:
> Hi, Rafael
> 
> > From: linux-acpi-ow...@vger.kernel.org 
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> > Wysocki
> > Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> > 
> > On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> > > Hi, Rafael.
> > >
> > > I agree with you and I added my opinion below.
> > >
> > > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> > >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> > >>> Hi, Rafeal.
> > >>>
> > >>> I added my opinion below.
> > >>>
> > >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> > >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> > >>> >> Hi, Rafael.
> > >>> >>
> > >>> >> I added my opinion below.
> > >>> >>
> > >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> > >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> > >>> >> >> Hi, Lv Zheng.
> > >>> >> >>
> > >>> >> >> I added my handcrafted ACPI table under your request, because
> > >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> > >>> >> >>
> > >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> > >>> >> >> > Hello,
> > >>> >> >> >
> > >>> >> >> > I attached the test results below,
> > >>> >> >> >
> > >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> > >>> >> >> > :
> > >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> > >>> >> >> >>> Hi,
> > >>> >> >> >>>
> > >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> > >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> > Behalf Of Seunghun
> > >>> >> >> >>> > Han
> > >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache 
> > >>> >> >> >>> > leak
> > >>> >> >> >>> >
> > >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> > >>> >> >> >>> > Institute of
> > >>> >> >> >>> > South Korea.
> > >>> >> >> >>> >
> > >>> >> >> >>> > I have been doing a research on ACPI and making a 
> > >>> >> >> >>> > handcrafted ACPI table
> > >>> >> >> >>> > for my research.
> > >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> > >>> >> >> >>> > kernel while boot
> > >>> >> >> >>> > process, and Linux kernel goes well without critical 
> > >>> >> >> >>> > problems.
> > >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
> > >>> >> >> >>> > abort cases.
> > >>> >> >> >>> >
> > >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> > >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> > >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> > >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> > >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator 
> > >>> >> >> >>> > >Device)
> > >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> > >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> > >>> >> >> >>> > >install System 

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, Rafael

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
> > Hi, Rafael.
> >
> > I agree with you and I added my opinion below.
> >
> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >>> Hi, Rafeal.
> >>>
> >>> I added my opinion below.
> >>>
> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >>> >> Hi, Rafael.
> >>> >>
> >>> >> I added my opinion below.
> >>> >>
> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >>> >> >> Hi, Lv Zheng.
> >>> >> >>
> >>> >> >> I added my handcrafted ACPI table under your request, because
> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>> >> >>
> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> >>> >> >> > Hello,
> >>> >> >> >
> >>> >> >> > I attached the test results below,
> >>> >> >> >
> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >>> >> >> > <r...@rjwysocki.net>:
> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> >> >> >>> Hi,
> >>> >> >> >>>
> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> Behalf Of Seunghun
> >>> >> >> >>> > Han
> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >> >> >>> >
> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >>> >> >> >>> > Institute of
> >>> >> >> >>> > South Korea.
> >>> >> >> >>> >
> >>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >>> >> >> >>> > ACPI table
> >>> >> >> >>> > for my research.
> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >>> >> >> >>> > kernel while boot
> >>> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >>> >> >> >>> > cases.
> >>> >> >> >>> >
> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >>> >> >> >>> > >install System Control
> Interrupt handler
> >>> >> >> >>> > (20160930/evevent-131)
> >>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> >> >> >>> > >(20160930/evmisc-281)
> &

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, Rafael

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> > Hi, Rafael.
> >
> > I agree with you and I added my opinion below.
> >
> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >>> Hi, Rafeal.
> >>>
> >>> I added my opinion below.
> >>>
> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >>> >> Hi, Rafael.
> >>> >>
> >>> >> I added my opinion below.
> >>> >>
> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >>> >> >> Hi, Lv Zheng.
> >>> >> >>
> >>> >> >> I added my handcrafted ACPI table under your request, because
> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>> >> >>
> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >>> >> >> > Hello,
> >>> >> >> >
> >>> >> >> > I attached the test results below,
> >>> >> >> >
> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >>> >> >> > :
> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> >> >> >>> Hi,
> >>> >> >> >>>
> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> Behalf Of Seunghun
> >>> >> >> >>> > Han
> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >> >> >>> >
> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >>> >> >> >>> > Institute of
> >>> >> >> >>> > South Korea.
> >>> >> >> >>> >
> >>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >>> >> >> >>> > ACPI table
> >>> >> >> >>> > for my research.
> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >>> >> >> >>> > kernel while boot
> >>> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >>> >> >> >>> > cases.
> >>> >> >> >>> >
> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >>> >> >> >>> > >install System Control
> Interrupt handler
> >>> >> >> >>> > (20160930/evevent-131)
> >>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> >> >> >>> > >(20160930/evmisc-281)
> >>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
> >>> >> >> >

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
> Hi, Rafael.
>
> I agree with you and I added my opinion below.
>
> 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>>> Hi, Rafeal.
>>>
>>> I added my opinion below.
>>>
>>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>>> >> Hi, Rafael.
>>> >>
>>> >> I added my opinion below.
>>> >>
>>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>>> >> >> Hi, Lv Zheng.
>>> >> >>
>>> >> >> I added my handcrafted ACPI table under your request, because
>>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>>> >> >>
>>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
>>> >> >> > Hello,
>>> >> >> >
>>> >> >> > I attached the test results below,
>>> >> >> >
>>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>:
>>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>>> >> >> >>> Hi,
>>> >> >> >>>
>>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>>> >> >> >>> > Han
>>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>> >> >> >>> >
>>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>>> >> >> >>> > Institute of
>>> >> >> >>> > South Korea.
>>> >> >> >>> >
>>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
>>> >> >> >>> > ACPI table
>>> >> >> >>> > for my research.
>>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>>> >> >> >>> > kernel while boot
>>> >> >> >>> > process, and Linux kernel goes well without critical problems.
>>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
>>> >> >> >>> > cases.
>>> >> >> >>> >
>>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>>> >> >> >>> > >install System Control Interrupt handler
>>> >> >> >>> > (20160930/evevent-131)
>>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>>> >> >> >>> > >(20160930/evmisc-281)
>>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
>>> >> >> >>> > >still has objects
>>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>>> >> >> >>> > >4.10.0-rc3 #2
>>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
>>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>>> >> 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> Hi, Rafael.
>
> I agree with you and I added my opinion below.
>
> 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
>> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>>> Hi, Rafeal.
>>>
>>> I added my opinion below.
>>>
>>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
>>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>>> >> Hi, Rafael.
>>> >>
>>> >> I added my opinion below.
>>> >>
>>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>>> >> >> Hi, Lv Zheng.
>>> >> >>
>>> >> >> I added my handcrafted ACPI table under your request, because
>>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>>> >> >>
>>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>>> >> >> > Hello,
>>> >> >> >
>>> >> >> > I attached the test results below,
>>> >> >> >
>>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>>> >> >> >>> Hi,
>>> >> >> >>>
>>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>>> >> >> >>> > Han
>>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>> >> >> >>> >
>>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>>> >> >> >>> > Institute of
>>> >> >> >>> > South Korea.
>>> >> >> >>> >
>>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
>>> >> >> >>> > ACPI table
>>> >> >> >>> > for my research.
>>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>>> >> >> >>> > kernel while boot
>>> >> >> >>> > process, and Linux kernel goes well without critical problems.
>>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
>>> >> >> >>> > cases.
>>> >> >> >>> >
>>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>>> >> >> >>> > >install System Control Interrupt handler
>>> >> >> >>> > (20160930/evevent-131)
>>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>>> >> >> >>> > >(20160930/evmisc-281)
>>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
>>> >> >> >>> > >still has objects
>>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>>> >> >> >>> > >4.10.0-rc3 #2
>>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
>>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>>> >> >> >>> > >[0.188000] Call Trace:
>>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafael.

I agree with you and I added my opinion below.

2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> Hi, Rafeal.
>>
>> I added my opinion below.
>>
>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> >> Hi, Rafael.
>> >>
>> >> I added my opinion below.
>> >>
>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> >> Hi, Lv Zheng.
>> >> >>
>> >> >> I added my handcrafted ACPI table under your request, because
>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >> >>
>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
>> >> >> > Hello,
>> >> >> >
>> >> >> > I attached the test results below,
>> >> >> >
>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>:
>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >> >> >>> > Han
>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >> >>> >
>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >> >> >>> > Institute of
>> >> >> >>> > South Korea.
>> >> >> >>> >
>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
>> >> >> >>> > ACPI table
>> >> >> >>> > for my research.
>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>> >> >> >>> > kernel while boot
>> >> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
>> >> >> >>> > cases.
>> >> >> >>> >
>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>> >> >> >>> > >install System Control Interrupt handler
>> >> >> >>> > (20160930/evevent-131)
>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >> >> >>> > >(20160930/evmisc-281)
>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
>> >> >> >>> > >still has objects
>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> >> >> >>> > >4.10.0-rc3 #2
>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>> >> >> >>> > >[0.188000] Call Trace:
>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >&g

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafael.

I agree with you and I added my opinion below.

2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> Hi, Rafeal.
>>
>> I added my opinion below.
>>
>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> >> Hi, Rafael.
>> >>
>> >> I added my opinion below.
>> >>
>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> >> Hi, Lv Zheng.
>> >> >>
>> >> >> I added my handcrafted ACPI table under your request, because
>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >> >>
>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> >> >> > Hello,
>> >> >> >
>> >> >> > I attached the test results below,
>> >> >> >
>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >> >> >>> > Han
>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >> >>> >
>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >> >> >>> > Institute of
>> >> >> >>> > South Korea.
>> >> >> >>> >
>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
>> >> >> >>> > ACPI table
>> >> >> >>> > for my research.
>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>> >> >> >>> > kernel while boot
>> >> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
>> >> >> >>> > cases.
>> >> >> >>> >
>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>> >> >> >>> > >install System Control Interrupt handler
>> >> >> >>> > (20160930/evevent-131)
>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >> >> >>> > >(20160930/evmisc-281)
>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
>> >> >> >>> > >still has objects
>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> >> >> >>> > >4.10.0-rc3 #2
>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>> >> >> >>> > >[0.188000] Call Trace:
>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >> >> >>> > >[0.18

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> Hi, Rafeal.
> 
> I added my opinion below.
> 
> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >> Hi, Rafael.
> >>
> >> I added my opinion below.
> >>
> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> >> Hi, Lv Zheng.
> >> >>
> >> >> I added my handcrafted ACPI table under your request, because
> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >> >>
> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> >> >> > Hello,
> >> >> >
> >> >> > I attached the test results below,
> >> >> >
> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>:
> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >> >> >>> > Han
> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >> >> >>> >
> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >> >> >>> > Institute of
> >> >> >>> > South Korea.
> >> >> >>> >
> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >> >> >>> > ACPI table
> >> >> >>> > for my research.
> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >> >> >>> > kernel while boot
> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >> >> >>> > cases.
> >> >> >>> >
> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >> >> >>> > >install System Control Interrupt handler
> >> >> >>> > (20160930/evevent-131)
> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >> >> >>> > >(20160930/evmisc-281)
> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
> >> >> >>> > >has objects
> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> >> >> >>> > >4.10.0-rc3 #2
> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> >> >> >>> > >[0.188000] Call Trace:
> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >> >> >>> > >[0.188000]  ? __cl

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> Hi, Rafeal.
> 
> I added my opinion below.
> 
> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >> Hi, Rafael.
> >>
> >> I added my opinion below.
> >>
> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> >> Hi, Lv Zheng.
> >> >>
> >> >> I added my handcrafted ACPI table under your request, because
> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >> >>
> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >> >> > Hello,
> >> >> >
> >> >> > I attached the test results below,
> >> >> >
> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >> >> >>> > Han
> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >> >> >>> >
> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >> >> >>> > Institute of
> >> >> >>> > South Korea.
> >> >> >>> >
> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >> >> >>> > ACPI table
> >> >> >>> > for my research.
> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >> >> >>> > kernel while boot
> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >> >> >>> > cases.
> >> >> >>> >
> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >> >> >>> > >install System Control Interrupt handler
> >> >> >>> > (20160930/evevent-131)
> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >> >> >>> > >(20160930/evmisc-281)
> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
> >> >> >>> > >has objects
> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> >> >> >>> > >4.10.0-rc3 #2
> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> >> >> >>> > >[0.188000] Call Trace:
> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >> >> >>> > >[0.188000]  ? video_setup+0

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafeal.

I added my opinion below.

2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> Hi, Rafael.
>>
>> I added my opinion below.
>>
>> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> Hi, Lv Zheng.
>> >>
>> >> I added my handcrafted ACPI table under your request, because
>> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>
>> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
>> >> > Hello,
>> >> >
>> >> > I attached the test results below,
>> >> >
>> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>:
>> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >> >>> > Han
>> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >>> >
>> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >> >>> > Institute of
>> >> >>> > South Korea.
>> >> >>> >
>> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
>> >> >>> > table
>> >> >>> > for my research.
>> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
>> >> >>> > while boot
>> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >> >>> >
>> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
>> >> >>> > >System Control Interrupt handler
>> >> >>> > (20160930/evevent-131)
>> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >> >>> > >(20160930/evmisc-281)
>> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
>> >> >>> > >has objects
>> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> >> >>> > >4.10.0-rc3 #2
>> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
>> >> >>> > >BIOS VirtualBox 12/01/2006
>> >> >>> > >[0.188000] Call Trace:
>> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >>

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafeal.

I added my opinion below.

2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> Hi, Rafael.
>>
>> I added my opinion below.
>>
>> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> Hi, Lv Zheng.
>> >>
>> >> I added my handcrafted ACPI table under your request, because
>> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>
>> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> >> > Hello,
>> >> >
>> >> > I attached the test results below,
>> >> >
>> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >> >>> > Han
>> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >>> >
>> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >> >>> > Institute of
>> >> >>> > South Korea.
>> >> >>> >
>> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
>> >> >>> > table
>> >> >>> > for my research.
>> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
>> >> >>> > while boot
>> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >> >>> >
>> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
>> >> >>> > >System Control Interrupt handler
>> >> >>> > (20160930/evevent-131)
>> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >> >>> > >(20160930/evmisc-281)
>> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
>> >> >>> > >has objects
>> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> >> >>> > >4.10.0-rc3 #2
>> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
>> >> >>> > >BIOS VirtualBox 12/01/2006
>> >> >>> > >[0.188000] Call Trace:
>> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >> >>>
>

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> Hi, Rafael.
> 
> I added my opinion below.
> 
> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> Hi, Lv Zheng.
> >>
> >> I added my handcrafted ACPI table under your request, because
> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>
> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> >> > Hello,
> >> >
> >> > I attached the test results below,
> >> >
> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>:
> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >>> Hi,
> >> >>>
> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >> >>> > Han
> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >> >>> >
> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >> >>> > Institute of
> >> >>> > South Korea.
> >> >>> >
> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
> >> >>> > table
> >> >>> > for my research.
> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
> >> >>> > while boot
> >> >>> > process, and Linux kernel goes well without critical problems.
> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
> >> >>> >
> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
> >> >>> > >System Control Interrupt handler
> >> >>> > (20160930/evevent-131)
> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >> >>> > >(20160930/evmisc-281)
> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
> >> >>> > >has objects
> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 
> >> >>> > >#2
> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
> >> >>> > >BIOS VirtualBox 12/01/2006
> >> >>> > >[0.188000] Call Trace:
> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >> >>>
> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >> >>> So could you send us the handcrafted ACPI table or both the "acpidump 
> >> >>> -c on" and "acpidump -c off" output?
> >>
> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> >> Here are raw dumps of table.
> >
> > So, excuse me, but what's the security issue here?
> >
> > You hacked your ACPI tables into pieces which requires root privileges 
> > anyway.
> >
> > Thanks,
> > Rafael
> >
> 
> As you mentioned earlier, I hacked my ACPI table for research, so it seems 
> that
> it is not a security issue.
> 
> But, if new mainboard are released and they have a vendor-specific ACPI table
> which has invalid data, the old version of kernel (<=4.9) will possibly expose
> kernel address and KASLR will be neutralized unintentionally.

But that would mean a basically non-functional system, so I'm not sure how
anyone can actually take advantage of the "KASLR neutralization".

> I know the vendors collaborate with Linux kernel developers, but the problem
> can still occur.
> 
> Hardware vendors release so many kinds of mainboard in a year, and the major
> Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.
> 
> For this reason, I think this issue has a security aspect.

Well, not quite IMO.

If the system needs ACPI tables and the kernel cannot use them, it just won't
work no matter what.

Thanks,
Rafael

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> Hi, Rafael.
> 
> I added my opinion below.
> 
> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> Hi, Lv Zheng.
> >>
> >> I added my handcrafted ACPI table under your request, because
> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>
> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >> > Hello,
> >> >
> >> > I attached the test results below,
> >> >
> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >>> Hi,
> >> >>>
> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >> >>> > Han
> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >> >>> >
> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >> >>> > Institute of
> >> >>> > South Korea.
> >> >>> >
> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
> >> >>> > table
> >> >>> > for my research.
> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
> >> >>> > while boot
> >> >>> > process, and Linux kernel goes well without critical problems.
> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
> >> >>> >
> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
> >> >>> > >System Control Interrupt handler
> >> >>> > (20160930/evevent-131)
> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >> >>> > >(20160930/evmisc-281)
> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
> >> >>> > >has objects
> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 
> >> >>> > >#2
> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
> >> >>> > >BIOS VirtualBox 12/01/2006
> >> >>> > >[0.188000] Call Trace:
> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >> >>>
> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >> >>> So could you send us the handcrafted ACPI table or both the "acpidump 
> >> >>> -c on" and "acpidump -c off" output?
> >>
> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> >> Here are raw dumps of table.
> >
> > So, excuse me, but what's the security issue here?
> >
> > You hacked your ACPI tables into pieces which requires root privileges 
> > anyway.
> >
> > Thanks,
> > Rafael
> >
> 
> As you mentioned earlier, I hacked my ACPI table for research, so it seems 
> that
> it is not a security issue.
> 
> But, if new mainboard are released and they have a vendor-specific ACPI table
> which has invalid data, the old version of kernel (<=4.9) will possibly expose
> kernel address and KASLR will be neutralized unintentionally.

But that would mean a basically non-functional system, so I'm not sure how
anyone can actually take advantage of the "KASLR neutralization".

> I know the vendors collaborate with Linux kernel developers, but the problem
> can still occur.
> 
> Hardware vendors release so many kinds of mainboard in a year, and the major
> Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.
> 
> For this reason, I think this issue has a security aspect.

Well, not quite IMO.

If the system needs ACPI tables and the kernel cannot use them, it just won't
work no matter what.

Thanks,
Rafael

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafael.

I added my opinion below.

2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> Hi, Lv Zheng.
>>
>> I added my handcrafted ACPI table under your request, because
>> "acpidump -c on" and "acpidump -c off" doesn't work.
>>
>> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
>> > Hello,
>> >
>> > I attached the test results below,
>> >
>> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>:
>> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >>> Hi,
>> >>>
>> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >>> > Han
>> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >>> >
>> >>> > I'm Seunghun Han, and I work for National Security Research Institute 
>> >>> > of
>> >>> > South Korea.
>> >>> >
>> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
>> >>> > table
>> >>> > for my research.
>> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
>> >>> > while boot
>> >>> > process, and Linux kernel goes well without critical problems.
>> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >>> >
>> >>> > Boot log of ACPI operand cache leak is as follows:
>> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
>> >>> > >System Control Interrupt handler
>> >>> > (20160930/evevent-131)
>> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >>> > >(20160930/evmisc-281)
>> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
>> >>> > >objects
>> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
>> >>> > >BIOS VirtualBox 12/01/2006
>> >>> > >[0.188000] Call Trace:
>> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >>>
>> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
>> >>> on" and "acpidump -c off" output?
>>
>> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> Here are raw dumps of table.
>
> So, excuse me, but what's the security issue here?
>
> You hacked your ACPI tables into pieces which requires root privileges anyway.
>
> Thanks,
> Rafael
>

As you mentioned earlier, I hacked my ACPI table for research, so it seems that
it is not a security issue.

But, if new mainboard are released and they have a vendor-specific ACPI table
which has invalid data, the old version of kernel (<=4.9) will possibly expose
kernel address and KASLR will be neutralized unintentionally.

I know the vendors collaborate with Linux kernel developers, but the problem
can still occur.

Hardware vendors release so many kinds of mainboard in a year, and the major
Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.

For this reason, I think this issue has a security aspect.

Thank you.

Best regards.

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafael.

I added my opinion below.

2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> Hi, Lv Zheng.
>>
>> I added my handcrafted ACPI table under your request, because
>> "acpidump -c on" and "acpidump -c off" doesn't work.
>>
>> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> > Hello,
>> >
>> > I attached the test results below,
>> >
>> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >>> Hi,
>> >>>
>> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >>> > Han
>> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >>> >
>> >>> > I'm Seunghun Han, and I work for National Security Research Institute 
>> >>> > of
>> >>> > South Korea.
>> >>> >
>> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
>> >>> > table
>> >>> > for my research.
>> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
>> >>> > while boot
>> >>> > process, and Linux kernel goes well without critical problems.
>> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >>> >
>> >>> > Boot log of ACPI operand cache leak is as follows:
>> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
>> >>> > >System Control Interrupt handler
>> >>> > (20160930/evevent-131)
>> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >>> > >(20160930/evmisc-281)
>> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
>> >>> > >objects
>> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
>> >>> > >BIOS VirtualBox 12/01/2006
>> >>> > >[0.188000] Call Trace:
>> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >>>
>> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
>> >>> on" and "acpidump -c off" output?
>>
>> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> Here are raw dumps of table.
>
> So, excuse me, but what's the security issue here?
>
> You hacked your ACPI tables into pieces which requires root privileges anyway.
>
> Thanks,
> Rafael
>

As you mentioned earlier, I hacked my ACPI table for research, so it seems that
it is not a security issue.

But, if new mainboard are released and they have a vendor-specific ACPI table
which has invalid data, the old version of kernel (<=4.9) will possibly expose
kernel address and KASLR will be neutralized unintentionally.

I know the vendors collaborate with Linux kernel developers, but the problem
can still occur.

Hardware vendors release so many kinds of mainboard in a year, and the major
Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.

For this reason, I think this issue has a security aspect.

Thank you.

Best regards.

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> Hi, Lv Zheng.
> 
> I added my handcrafted ACPI table under your request, because
> "acpidump -c on" and "acpidump -c off" doesn't work.
> 
> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> > Hello,
> >
> > I attached the test results below,
> >
> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>:
> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >>> > Han
> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >
> >>> > I'm Seunghun Han, and I work for National Security Research Institute of
> >>> > South Korea.
> >>> >
> >>> > I have been doing a research on ACPI and making a handcrafted ACPI table
> >>> > for my research.
> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
> >>> > while boot
> >>> > process, and Linux kernel goes well without critical problems.
> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
> >>> >
> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
> >>> > >System Control Interrupt handler
> >>> > (20160930/evevent-131)
> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> > >(20160930/evmisc-281)
> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
> >>> > >objects
> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
> >>> > >VirtualBox 12/01/2006
> >>> > >[0.188000] Call Trace:
> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >>>
> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
> >>> on" and "acpidump -c off" output?
> 
> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> Here are raw dumps of table.

So, excuse me, but what's the security issue here?

You hacked your ACPI tables into pieces which requires root privileges anyway.

Thanks,
Rafael

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> Hi, Lv Zheng.
> 
> I added my handcrafted ACPI table under your request, because
> "acpidump -c on" and "acpidump -c off" doesn't work.
> 
> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> > Hello,
> >
> > I attached the test results below,
> >
> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >>> > Han
> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >
> >>> > I'm Seunghun Han, and I work for National Security Research Institute of
> >>> > South Korea.
> >>> >
> >>> > I have been doing a research on ACPI and making a handcrafted ACPI table
> >>> > for my research.
> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
> >>> > while boot
> >>> > process, and Linux kernel goes well without critical problems.
> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
> >>> >
> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
> >>> > >System Control Interrupt handler
> >>> > (20160930/evevent-131)
> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> > >(20160930/evmisc-281)
> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
> >>> > >objects
> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
> >>> > >VirtualBox 12/01/2006
> >>> > >[0.188000] Call Trace:
> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >>>
> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
> >>> on" and "acpidump -c off" output?
> 
> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> Here are raw dumps of table.

So, excuse me, but what's the security issue here?

You hacked your ACPI tables into pieces which requires root privileges anyway.

Thanks,
Rafael

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Lv Zheng.

I added my handcrafted ACPI table under your request, because
"acpidump -c on" and "acpidump -c off" doesn't work.

2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> Hello,
>
> I attached the test results below,
>
> 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <r...@rjwysocki.net>:
>> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>>> Hi,
>>>
>>> > From: linux-acpi-ow...@vger.kernel.org 
>>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>>> > Han
>>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>> >
>>> > I'm Seunghun Han, and I work for National Security Research Institute of
>>> > South Korea.
>>> >
>>> > I have been doing a research on ACPI and making a handcrafted ACPI table
>>> > for my research.
>>> > Errors of handcrafted ACPI tables are handled well in Linux kernel while 
>>> > boot
>>> > process, and Linux kernel goes well without critical problems.
>>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>>> >
>>> > Boot log of ACPI operand cache leak is as follows:
>>> > >[0.174332] ACPI: Added _OSI(Module Device)
>>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System 
>>> > >Control Interrupt handler
>>> > (20160930/evevent-131)
>>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>>> > >(20160930/evmisc-281)
>>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
>>> > >objects
>>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
>>> > >VirtualBox 12/01/2006
>>> > >[0.188000] Call Trace:
>>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>>> > >[0.188000]  ? acpi_init+0x288/0x32e
>>> > >[0.188000]  ? __class_create+0x4c/0x80
>>> > >[0.188000]  ? video_setup+0x7a/0x7a
>>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>>> > >[0.188000]  ? rest_init+0x80/0x80
>>> > >[0.188000]  ? kernel_init+0xa/0x100
>>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>>>
>>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
>>> on" and "acpidump -c off" output?

I modified FACP, FACS, APIC table in VirtualBox for Linux.
Here are raw dumps of table.

[0.00] ACPI: FACP 0xDFFF00F0 F4 (v04 VBOX
VBOXFACP 0001 ASL  0061)
[0.00] FACP DUMP
[0.00] 0x: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20
[0.00] 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20
[0.00] 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41
[0.00] 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00
[0.00] 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00
[0.00] 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00
[0.00] 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00
[0.00] 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00
[0.00] 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF
[0.00] 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00
[0.00] 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02
[0.00] 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01
[0.00] 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00F0: 00 00 0

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Lv Zheng.

I added my handcrafted ACPI table under your request, because
"acpidump -c on" and "acpidump -c off" doesn't work.

2017-02-21 19:36 GMT+09:00 Seunghun Han :
> Hello,
>
> I attached the test results below,
>
> 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>>> Hi,
>>>
>>> > From: linux-acpi-ow...@vger.kernel.org 
>>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>>> > Han
>>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>> >
>>> > I'm Seunghun Han, and I work for National Security Research Institute of
>>> > South Korea.
>>> >
>>> > I have been doing a research on ACPI and making a handcrafted ACPI table
>>> > for my research.
>>> > Errors of handcrafted ACPI tables are handled well in Linux kernel while 
>>> > boot
>>> > process, and Linux kernel goes well without critical problems.
>>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>>> >
>>> > Boot log of ACPI operand cache leak is as follows:
>>> > >[0.174332] ACPI: Added _OSI(Module Device)
>>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System 
>>> > >Control Interrupt handler
>>> > (20160930/evevent-131)
>>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>>> > >(20160930/evmisc-281)
>>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
>>> > >objects
>>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
>>> > >VirtualBox 12/01/2006
>>> > >[0.188000] Call Trace:
>>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>>> > >[0.188000]  ? acpi_init+0x288/0x32e
>>> > >[0.188000]  ? __class_create+0x4c/0x80
>>> > >[0.188000]  ? video_setup+0x7a/0x7a
>>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>>> > >[0.188000]  ? rest_init+0x80/0x80
>>> > >[0.188000]  ? kernel_init+0xa/0x100
>>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>>>
>>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
>>> on" and "acpidump -c off" output?

I modified FACP, FACS, APIC table in VirtualBox for Linux.
Here are raw dumps of table.

[0.00] ACPI: FACP 0xDFFF00F0 F4 (v04 VBOX
VBOXFACP 0001 ASL  0061)
[0.00] FACP DUMP
[0.00] 0x: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20
[0.00] 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20
[0.00] 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41
[0.00] 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00
[0.00] 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00
[0.00] 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00
[0.00] 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00
[0.00] 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00
[0.00] 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF
[0.00] 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00
[0.00] 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02
[0.00] 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01
[0.00] 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00F0: 00 00 00 00

[0.00] ACPI: FACS 0xDFFF0200 000

[PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.

I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without critical problems.
But I found some ACPI operand cache leaks in ACPI early abort cases.

Boot log of ACPI operand cache leak is as follows:
>[0.174332] ACPI: Added _OSI(Module Device)
>[0.175504] ACPI: Added _OSI(Processor Device)
>[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>[0.178284] ACPI: SCI (IRQ16705) allocation failed
>[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System 
>Control Interrupt handler (20160930/evevent-131)
>[0.180008] ACPI: Unable to start the ACPI Interpreter
>[0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281)
>[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
>VirtualBox 12/01/2006
>[0.188000] Call Trace:
>[0.188000]  ? dump_stack+0x5c/0x7d
>[0.188000]  ? kmem_cache_destroy+0x224/0x230
>[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>[0.188000]  ? acpi_terminate+0x5/0xf
>[0.188000]  ? acpi_init+0x288/0x32e
>[0.188000]  ? __class_create+0x4c/0x80
>[0.188000]  ? video_setup+0x7a/0x7a
>[0.188000]  ? do_one_initcall+0x4e/0x1b0
>[0.188000]  ? kernel_init_freeable+0x194/0x21a
>[0.188000]  ? rest_init+0x80/0x80
>[0.188000]  ? kernel_init+0xa/0x100
>[0.188000]  ? 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_ns_terminate() function to delete namespace data
and ACPI operand cache (acpi_gbl_module_code_list).

But the deletion code in acpi_ns_terminate() function is wrapped in
ACPI_EXEC_APP definition, therefore the code is only executed when the
definition exists.
If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is
leaked, and stack dump is shown in kernel log.

This causes a security threat because the old kernel (<= 4.9) shows memory
locations of kernel functions in stack dump, therefore kernel ASLR can be
neutralized.

To fix ACPI operand leak for enhancing security, I made a patch which removes
the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the
deletion code unconditionally.

I hope that this patch improves the security of Linux kernel.

Thank you.

Signed-off-by: Seunghun Han 
---
Changes since v1: move position of variables to remove compile warning.

drivers/acpi/acpica/nsutils.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 691814d..943702d 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -594,25 +594,20 @@ struct acpi_namespace_node 
*acpi_ns_validate_handle(acpi_handle handle)
 void acpi_ns_terminate(void)
 {
acpi_status status;
+   union acpi_operand_object *prev;
+   union acpi_operand_object *next;
 
ACPI_FUNCTION_TRACE(ns_terminate);
 
-#ifdef ACPI_EXEC_APP
-   {
-   union acpi_operand_object *prev;
-   union acpi_operand_object *next;
+   /* Delete any module-level code blocks */
 
-   /* Delete any module-level code blocks */
-
-   next = acpi_gbl_module_code_list;
-   while (next) {
-   prev = next;
-   next = next->method.mutex;
-   prev->method.mutex = NULL;  /* Clear the Mutex 
(cheated) field */
-   acpi_ut_remove_reference(prev);
-   }
+   next = acpi_gbl_module_code_list;
+   while (next) {
+   prev = next;
+   next = next->method.mutex;
+   prev->method.mutex = NULL;  /* Clear the Mutex (cheated) 
field */
+   acpi_ut_remove_reference(prev);
}
-#endif
 
/*
 * Free the entire namespace -- all nodes and all objects
-- 
2.1.4

[PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.

I have been doing a research on ACPI and making a handcrafted ACPI table
for my research.
Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
process, and Linux kernel goes well without critical problems.
But I found some ACPI operand cache leaks in ACPI early abort cases.

Boot log of ACPI operand cache leak is as follows:
>[0.174332] ACPI: Added _OSI(Module Device)
>[0.175504] ACPI: Added _OSI(Processor Device)
>[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>[0.178284] ACPI: SCI (IRQ16705) allocation failed
>[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System 
>Control Interrupt handler (20160930/evevent-131)
>[0.180008] ACPI: Unable to start the ACPI Interpreter
>[0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281)
>[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
>VirtualBox 12/01/2006
>[0.188000] Call Trace:
>[0.188000]  ? dump_stack+0x5c/0x7d
>[0.188000]  ? kmem_cache_destroy+0x224/0x230
>[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>[0.188000]  ? acpi_terminate+0x5/0xf
>[0.188000]  ? acpi_init+0x288/0x32e
>[0.188000]  ? __class_create+0x4c/0x80
>[0.188000]  ? video_setup+0x7a/0x7a
>[0.188000]  ? do_one_initcall+0x4e/0x1b0
>[0.188000]  ? kernel_init_freeable+0x194/0x21a
>[0.188000]  ? rest_init+0x80/0x80
>[0.188000]  ? kernel_init+0xa/0x100
>[0.188000]  ? 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_ns_terminate() function to delete namespace data
and ACPI operand cache (acpi_gbl_module_code_list).

But the deletion code in acpi_ns_terminate() function is wrapped in
ACPI_EXEC_APP definition, therefore the code is only executed when the
definition exists.
If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is
leaked, and stack dump is shown in kernel log.

This causes a security threat because the old kernel (<= 4.9) shows memory
locations of kernel functions in stack dump, therefore kernel ASLR can be
neutralized.

To fix ACPI operand leak for enhancing security, I made a patch which removes
the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the
deletion code unconditionally.

I hope that this patch improves the security of Linux kernel.

Thank you.

Signed-off-by: Seunghun Han 
---
Changes since v1: move position of variables to remove compile warning.

drivers/acpi/acpica/nsutils.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 691814d..943702d 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -594,25 +594,20 @@ struct acpi_namespace_node 
*acpi_ns_validate_handle(acpi_handle handle)
 void acpi_ns_terminate(void)
 {
acpi_status status;
+   union acpi_operand_object *prev;
+   union acpi_operand_object *next;
 
ACPI_FUNCTION_TRACE(ns_terminate);
 
-#ifdef ACPI_EXEC_APP
-   {
-   union acpi_operand_object *prev;
-   union acpi_operand_object *next;
+   /* Delete any module-level code blocks */
 
-   /* Delete any module-level code blocks */
-
-   next = acpi_gbl_module_code_list;
-   while (next) {
-   prev = next;
-   next = next->method.mutex;
-   prev->method.mutex = NULL;  /* Clear the Mutex 
(cheated) field */
-   acpi_ut_remove_reference(prev);
-   }
+   next = acpi_gbl_module_code_list;
+   while (next) {
+   prev = next;
+   next = next->method.mutex;
+   prev->method.mutex = NULL;  /* Clear the Mutex (cheated) 
field */
+   acpi_ut_remove_reference(prev);
}
-#endif
 
/*
 * Free the entire namespace -- all nodes and all objects
-- 
2.1.4