Blame SOURCES/cve-2017-13693.patch

9897bb
From 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 Mon Sep 17 00:00:00 2001
9897bb
From: Seunghun Han <kkamagui@gmail.com>
9897bb
Date: Wed, 19 Jul 2017 16:47:53 +0900
9897bb
Subject: [PATCH] acpi: acpica: fix acpi operand cache leak in dswstate.c
9897bb
9897bb
I found an ACPI cache leak in ACPI early termination and boot continuing case.
9897bb
9897bb
When early termination occurs due to malicious ACPI table, Linux kernel
9897bb
terminates ACPI function and continues to boot process. While kernel terminates
9897bb
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
9897bb
9897bb
Boot log of ACPI operand cache leak is as follows:
9897bb
>[    0.585957] ACPI: Added _OSI(Module Device)
9897bb
>[    0.587218] ACPI: Added _OSI(Processor Device)
9897bb
>[    0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
9897bb
>[    0.589790] ACPI: Added _OSI(Processor Aggregator Device)
9897bb
>[    0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)
9897bb
>[    0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)
9897bb
>[    0.597858] ACPI: Unable to start the ACPI Interpreter
9897bb
>[    0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
9897bb
>[    0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
9897bb
>[    0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
9897bb
>[    0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
9897bb
>[    0.609177] Call Trace:
9897bb
>[    0.610063]  ? dump_stack+0x5c/0x81
9897bb
>[    0.611118]  ? kmem_cache_destroy+0x1aa/0x1c0
9897bb
>[    0.612632]  ? acpi_sleep_proc_init+0x27/0x27
9897bb
>[    0.613906]  ? acpi_os_delete_cache+0xa/0x10
9897bb
>[    0.617986]  ? acpi_ut_delete_caches+0x3f/0x7b
9897bb
>[    0.619293]  ? acpi_terminate+0xa/0x14
9897bb
>[    0.620394]  ? acpi_init+0x2af/0x34f
9897bb
>[    0.621616]  ? __class_create+0x4c/0x80
9897bb
>[    0.623412]  ? video_setup+0x7f/0x7f
9897bb
>[    0.624585]  ? acpi_sleep_proc_init+0x27/0x27
9897bb
>[    0.625861]  ? do_one_initcall+0x4e/0x1a0
9897bb
>[    0.627513]  ? kernel_init_freeable+0x19e/0x21f
9897bb
>[    0.628972]  ? rest_init+0x80/0x80
9897bb
>[    0.630043]  ? kernel_init+0xa/0x100
9897bb
>[    0.631084]  ? ret_from_fork+0x25/0x30
9897bb
>[    0.633343] vgaarb: loaded
9897bb
>[    0.635036] EDAC MC: Ver: 3.0.0
9897bb
>[    0.638601] PCI: Probing PCI hardware
9897bb
>[    0.639833] PCI host bridge to bus 0000:00
9897bb
>[    0.641031] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
9897bb
> ... Continue to boot and log is omitted ...
9897bb
9897bb
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
9897bb
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
9897bb
function uses walk_state->operand_index for start position of the top, but
9897bb
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
9897bb
Therefore, this causes acpi operand memory leak.
9897bb
9897bb
This cache leak causes a security threat because an old kernel (<= 4.9) shows
9897bb
memory locations of kernel functions in stack dump. Some malicious users
9897bb
could use this information to neutralize kernel ASLR.
9897bb
9897bb
I made a patch to fix ACPI operand cache leak.
9897bb
9897bb
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
9897bb
9897bb
Github-Location: https://github.com/acpica/acpica/pull/295/commits/987a3b5cf7175916e2a4b6ea5b8e70f830dfe732
9897bb
---
9897bb
 source/components/dispatcher/dsutils.c | 9 ++++++++-
9897bb
 1 file changed, 8 insertions(+), 1 deletion(-)
9897bb
9897bb
Index: acpica-unix2-20200925/source/components/dispatcher/dsutils.c
9897bb
===================================================================
9897bb
--- acpica-unix2-20200925.orig/source/components/dispatcher/dsutils.c
9897bb
+++ acpica-unix2-20200925/source/components/dispatcher/dsutils.c
9897bb
@@ -759,6 +759,8 @@ AcpiDsCreateOperands (
9897bb
     ACPI_PARSE_OBJECT       *Arguments[ACPI_OBJ_NUM_OPERANDS];
9897bb
     UINT32                  ArgCount = 0;
9897bb
     UINT32                  Index = WalkState->NumOperands;
9897bb
+    UINT32                  PrevNumOperands = WalkState->NumOperands;
9897bb
+    UINT32                  NewNumOperands;
9897bb
     UINT32                  i;
9897bb
 
9897bb
 
9897bb
@@ -791,6 +793,7 @@ AcpiDsCreateOperands (
9897bb
 
9897bb
     /* Create the interpreter arguments, in reverse order */
9897bb
 
9897bb
+    NewNumOperands = Index;
9897bb
     Index--;
9897bb
     for (i = 0; i < ArgCount; i++)
9897bb
     {
9897bb
@@ -818,7 +821,11 @@ Cleanup:
9897bb
      * pop everything off of the operand stack and delete those
9897bb
      * objects
9897bb
      */
9897bb
-    AcpiDsObjStackPopAndDelete (ArgCount, WalkState);
9897bb
+    WalkState->NumOperands = i;
9897bb
+    AcpiDsObjStackPopAndDelete (NewNumOperands, WalkState);
9897bb
+
9897bb
+    /* Restore operand count */
9897bb
+    WalkState->NumOperands = PrevNumOperands;
9897bb
 
9897bb
     ACPI_EXCEPTION ((AE_INFO, Status, "While creating Arg %u", Index));
9897bb
     return_ACPI_STATUS (Status);