4.12.11-200.fc25.gnu

10 files changed, 672 insertions, 94 deletions

diff --git a/freed-ora/current/f25/V4-acpi-acpica-fix-acpi-parse-and-parseext-cache-leaks.patch b/freed-ora/current/f25/V4-acpi-acpica-fix-acpi-parse-and-parseext-cache-leaks.patch
new file mode 100644
index 000000000..60cbe6c38
--- /dev/null
+++ b/freed-ora/current/f25/V4-acpi-acpica-fix-acpi-parse-and-parseext-cache-leaks.patch
@@ -0,0 +1,231 @@
+From patchwork Fri Jun 23 09:36:37 2017
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 8bit
+Subject: [V4] acpi: acpica: fix acpi parse and parseext cache leaks
+From: Seunghun Han <kkamagui@gmail.com>
+X-Patchwork-Id: 9806085
+Message-Id: <1498210597-112293-1-git-send-email-kkamagui@gmail.com>
+To: lv.zheng@intel.com
+Cc: robert.moore@intel.com, rafael.j.wysocki@intel.com,
+ linux-acpi@vger.kernel.org, devel@acpica.org,
+ linux-kernel@vger.kernel.org, Seunghun Han <kkamagui@gmail.com>
+Date: Fri, 23 Jun 2017 18:36:37 +0900
+
+I'm Seunghun Han, and I work for National Security Research Institute of
+South Korea.
+
+I have been doing a research on ACPI and found an ACPI cache leak in ACPI
+early abort cases.
+
+Boot log of ACPI cache leak is as follows:
+[    0.352414] ACPI: Added _OSI(Module Device)
+[    0.353182] ACPI: Added _OSI(Processor Device)
+[    0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    0.353182] ACPI: Added _OSI(Processor Aggregator Device)
+[    0.356028] ACPI: Unable to start the ACPI Interpreter
+[    0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
+[    0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects
+[    0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
+4.12.0-rc4-next-20170608+ #10
+[    0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
+VirtualBox 12/01/2006
+[    0.361873] Call Trace:
+[    0.362243]  ? dump_stack+0x5c/0x81
+[    0.362591]  ? kmem_cache_destroy+0x1aa/0x1c0
+[    0.362944]  ? acpi_sleep_proc_init+0x27/0x27
+[    0.363296]  ? acpi_os_delete_cache+0xa/0x10
+[    0.363646]  ? acpi_ut_delete_caches+0x6d/0x7b
+[    0.364000]  ? acpi_terminate+0xa/0x14
+[    0.364000]  ? acpi_init+0x2af/0x34f
+[    0.364000]  ? __class_create+0x4c/0x80
+[    0.364000]  ? video_setup+0x7f/0x7f
+[    0.364000]  ? acpi_sleep_proc_init+0x27/0x27
+[    0.364000]  ? do_one_initcall+0x4e/0x1a0
+[    0.364000]  ? kernel_init_freeable+0x189/0x20a
+[    0.364000]  ? rest_init+0xc0/0xc0
+[    0.364000]  ? kernel_init+0xa/0x100
+[    0.364000]  ? ret_from_fork+0x25/0x30
+
+I analyzed this memory leak in detail. I found that “Acpi-State” cache and
+“Acpi-Parse” cache were merged because the size of cache objects was same
+slab cache size.
+
+I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked
+using SLAB_NEVER_MERGE flag in kmem_cache_create() function.
+
+Real ACPI cache leak point is as follows:
+[    0.360101] ACPI: Added _OSI(Module Device)
+[    0.360101] ACPI: Added _OSI(Processor Device)
+[    0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    0.361043] ACPI: Added _OSI(Processor Aggregator Device)
+[    0.364016] ACPI: Unable to start the ACPI Interpreter
+[    0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
+[    0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects
+[    0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W
+4.12.0-rc4-next-20170608+ #8
+[    0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
+VirtualBox 12/01/2006
+[    0.372000] Call Trace:
+[    0.372000]  ? dump_stack+0x5c/0x81
+[    0.372000]  ? kmem_cache_destroy+0x1aa/0x1c0
+[    0.372000]  ? acpi_sleep_proc_init+0x27/0x27
+[    0.372000]  ? acpi_os_delete_cache+0xa/0x10
+[    0.372000]  ? acpi_ut_delete_caches+0x56/0x7b
+[    0.372000]  ? acpi_terminate+0xa/0x14
+[    0.372000]  ? acpi_init+0x2af/0x34f
+[    0.372000]  ? __class_create+0x4c/0x80
+[    0.372000]  ? video_setup+0x7f/0x7f
+[    0.372000]  ? acpi_sleep_proc_init+0x27/0x27
+[    0.372000]  ? do_one_initcall+0x4e/0x1a0
+[    0.372000]  ? kernel_init_freeable+0x189/0x20a
+[    0.372000]  ? rest_init+0xc0/0xc0
+[    0.372000]  ? kernel_init+0xa/0x100
+[    0.372000]  ? ret_from_fork+0x25/0x30
+[    0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects
+[    0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W
+4.12.0-rc4-next-20170608+ #8
+[    0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
+VirtualBox 12/01/2006
+[    0.392000] Call Trace:
+[    0.392000]  ? dump_stack+0x5c/0x81
+[    0.392000]  ? kmem_cache_destroy+0x1aa/0x1c0
+[    0.392000]  ? acpi_sleep_proc_init+0x27/0x27
+[    0.392000]  ? acpi_os_delete_cache+0xa/0x10
+[    0.392000]  ? acpi_ut_delete_caches+0x6d/0x7b
+[    0.392000]  ? acpi_terminate+0xa/0x14
+[    0.392000]  ? acpi_init+0x2af/0x34f
+[    0.392000]  ? __class_create+0x4c/0x80
+[    0.392000]  ? video_setup+0x7f/0x7f
+[    0.392000]  ? acpi_sleep_proc_init+0x27/0x27
+[    0.392000]  ? do_one_initcall+0x4e/0x1a0
+[    0.392000]  ? kernel_init_freeable+0x189/0x20a
+[    0.392000]  ? rest_init+0xc0/0xc0
+[    0.392000]  ? kernel_init+0xa/0x100
+[    0.392000]  ? ret_from_fork+0x25/0x30
+
+When early abort is occurred due to invalid ACPI information, Linux kernel
+terminates ACPI by calling acpi_terminate() function. The function calls
+acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_
+cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache).
+
+But the deletion codes in acpi_ut_delete_caches() function only delete
+slab caches using kmem_cache_destroy() function, therefore the cache
+objects should be flushed before acpi_ut_delete_caches() function.
+
+“Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse
+function, acpi_ps_parse_loop(). The function should have flush codes to
+handle an error state due to invalid AML codes.
+
+This cache leak has a security threat because an old kernel (<= 4.9) shows
+memory locations of kernel functions in stack dump. Some malicious users
+could use this information to neutralize kernel ASLR.
+
+To fix ACPI cache leak for enhancing security, I made a patch which has
+flush codes in acpi_ps_parse_loop() function.
+
+I hope that this patch improves the security of Linux kernel.
+
+Thank you.
+
+Signed-off-by: Seunghun Han <kkamagui@gmail.com>
+---
+Changes since v3: change control transfer according to reviewer's comments.
+Changes since v2: merge flush code with existing code and change comments.
+Changes since v1: move flush code to acpi_ps_complete_final_op() function.
+
+ drivers/acpi/acpica/psobject.c | 53 +++++++++++++-----------------------------
+ 1 file changed, 16 insertions(+), 37 deletions(-)
+
+diff --git a/drivers/acpi/acpica/psobject.c b/drivers/acpi/acpica/psobject.c
+index 5bcb618..4539391 100644
+--- a/drivers/acpi/acpica/psobject.c
++++ b/drivers/acpi/acpica/psobject.c
+@@ -608,7 +608,8 @@ acpi_status
+ acpi_ps_complete_final_op(struct acpi_walk_state *walk_state,
+ 			  union acpi_parse_object *op, acpi_status status)
+ {
+-	acpi_status status2;
++	acpi_status return_status = AE_OK;
++	u8 ascending = TRUE;
+ 
+ 	ACPI_FUNCTION_TRACE_PTR(ps_complete_final_op, walk_state);
+ 
+@@ -622,7 +623,8 @@ acpi_ps_complete_final_op(struct acpi_walk_state *walk_state,
+ 			  op));
+ 	do {
+ 		if (op) {
+-			if (walk_state->ascending_callback != NULL) {
++			if (ascending &&
++			    walk_state->ascending_callback != NULL) {
+ 				walk_state->op = op;
+ 				walk_state->op_info =
+ 				    acpi_ps_get_opcode_info(op->common.
+@@ -644,49 +646,26 @@ acpi_ps_complete_final_op(struct acpi_walk_state *walk_state,
+ 				}
+ 
+ 				if (status == AE_CTRL_TERMINATE) {
+-					status = AE_OK;
+-
+-					/* Clean up */
+-					do {
+-						if (op) {
+-							status2 =
+-							    acpi_ps_complete_this_op
+-							    (walk_state, op);
+-							if (ACPI_FAILURE
+-							    (status2)) {
+-								return_ACPI_STATUS
+-								    (status2);
+-							}
+-						}
+-
+-						acpi_ps_pop_scope(&
+-								  (walk_state->
+-								   parser_state),
+-								  &op,
+-								  &walk_state->
+-								  arg_types,
+-								  &walk_state->
+-								  arg_count);
+-
+-					} while (op);
+-
+-					return_ACPI_STATUS(status);
++					ascending = FALSE;
++					return_status = AE_CTRL_TERMINATE;
+ 				}
+ 
+ 				else if (ACPI_FAILURE(status)) {
+ 
+ 					/* First error is most important */
+ 
+-					(void)
+-					    acpi_ps_complete_this_op(walk_state,
+-								     op);
+-					return_ACPI_STATUS(status);
++					ascending = FALSE;
++					return_status = status;
+ 				}
+ 			}
+ 
+-			status2 = acpi_ps_complete_this_op(walk_state, op);
+-			if (ACPI_FAILURE(status2)) {
+-				return_ACPI_STATUS(status2);
++			status = acpi_ps_complete_this_op(walk_state, op);
++			if (ACPI_FAILURE(status)) {
++				ascending = FALSE;
++				if (ACPI_SUCCESS(return_status) ||
++				    return_status == AE_CTRL_TERMINATE) {
++					return_status = status;
++				}
+ 			}
+ 		}
+ 
+@@ -696,5 +675,5 @@ acpi_ps_complete_final_op(struct acpi_walk_state *walk_state,
+ 
+ 	} while (op);
+ 
+-	return_ACPI_STATUS(status);
++	return_ACPI_STATUS(return_status);
+ }
diff --git a/freed-ora/current/f25/acpi-acpica-fix-acpi-operand-cache-leak-in-dsutils.c.patch b/freed-ora/current/f25/acpi-acpica-fix-acpi-operand-cache-leak-in-dsutils.c.patch
new file mode 100644
index 000000000..9825deb9a
--- /dev/null
+++ b/freed-ora/current/f25/acpi-acpica-fix-acpi-operand-cache-leak-in-dsutils.c.patch
@@ -0,0 +1,107 @@
+From patchwork Thu Aug 24 05:11:35 2017
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: acpi: acpica: fix acpi operand cache leak in dsutils.c
+From: Seunghun Han <kkamagui@gmail.com>
+X-Patchwork-Id: 9919053
+Message-Id: <1503551495-33286-1-git-send-email-kkamagui@gmail.com>
+To: lv.zheng@intel.com
+Cc: robert.moore@intel.com, rafael.j.wysocki@intel.com,
+ linux-acpi@vger.kernel.org, devel@acpica.org,
+ linux-kernel@vger.kernel.org, security@kernel.org,
+ Seunghun Han <kkamagui@gmail.com>
+Date: Thu, 24 Aug 2017 14:11:35 +0900
+
+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: C806E00000004002/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.611118]  ? 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 0000:00
+>[    0.641031] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
+> ... 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 <kkamagui@gmail.com>
+---
+ drivers/acpi/acpica/dsutils.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c
+index 0dabd9b..2c8a060 100644
+--- a/drivers/acpi/acpica/dsutils.c
++++ b/drivers/acpi/acpica/dsutils.c
+@@ -705,6 +705,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
+ 	union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS];
+ 	u32 arg_count = 0;
+ 	u32 index = walk_state->num_operands;
++	u32 prev_num_operands = walk_state->num_operands;
++	u32 new_num_operands;
+ 	u32 i;
+ 
+ 	ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg);
+@@ -733,6 +735,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
+ 
+ 	/* Create the interpreter arguments, in reverse order */
+ 
++	new_num_operands = index;
+ 	index--;
+ 	for (i = 0; i < arg_count; i++) {
+ 		arg = arguments[index];
+@@ -757,7 +760,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
+ 	 * pop everything off of the operand stack and delete those
+ 	 * objects
+ 	 */
+-	acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state);
++	walk_state->num_operands = i;
++	acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state);
++
++	/* Restore operand count */
++	walk_state->num_operands = prev_num_operands;
+ 
+ 	ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index));
+ 	return_ACPI_STATUS(status);
diff --git a/freed-ora/current/f25/acpi-acpica-fix-acpi-operand-cache-leak-in-nseval.c.patch b/freed-ora/current/f25/acpi-acpica-fix-acpi-operand-cache-leak-in-nseval.c.patch
new file mode 100644
index 000000000..3623a4ebd
--- /dev/null
+++ b/freed-ora/current/f25/acpi-acpica-fix-acpi-operand-cache-leak-in-nseval.c.patch
@@ -0,0 +1,96 @@
+From patchwork Wed Jul 19 07:07:23 2017
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: acpi: acpica: fix acpi operand cache leak in nseval.c
+From: Seunghun Han <kkamagui@gmail.com>
+X-Patchwork-Id: 9850567
+Message-Id: <1500448043-137615-1-git-send-email-kkamagui@gmail.com>
+To: Lv Zheng <lv.zheng@intel.com>
+Cc: Robert Moore <robert.moore@intel.com>,
+ "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
+ linux-acpi@vger.kernel.org, devel@acpica.org,
+ linux-kernel@vger.kernel.org, security@kernel.org,
+ Seunghun Han <kkamagui@gmail.com>
+Date: Wed, 19 Jul 2017 16:07:23 +0900
+
+I found an ACPI cache leak in ACPI early termination and boot continuing case.
+
+When early termination occurs 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.464168] ACPI: Added _OSI(Module Device)
+>[    0.467022] ACPI: Added _OSI(Processor Device)
+>[    0.469376] ACPI: Added _OSI(3.0 _SCP Extensions)
+>[    0.471647] ACPI: Added _OSI(Processor Aggregator Device)
+>[    0.477997] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174)
+>[    0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] (20170303/dswexec-461)
+>[    0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
+>[    0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node ffff88021710a618), AE_AML_INTERNAL (20170303/psparse-543)
+>[    0.497683] ACPI: Interpreter enabled
+>[    0.499385] ACPI: (supports S0)
+>[    0.501151] ACPI: Using IOAPIC for interrupt routing
+>[    0.503342] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174)
+>[    0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] (20170303/dswexec-461)
+>[    0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
+>[    0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node ffff88021710ab18), AE_AML_INTERNAL (20170303/psparse-543)
+>[    0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC (20170303/bus-991)
+>[    0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
+>[    0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
+>[    0.526795] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
+>[    0.529668] Call Trace:
+>[    0.530811]  ? dump_stack+0x5c/0x81
+>[    0.532240]  ? kmem_cache_destroy+0x1aa/0x1c0
+>[    0.533905]  ? acpi_os_delete_cache+0xa/0x10
+>[    0.535497]  ? acpi_ut_delete_caches+0x3f/0x7b
+>[    0.537237]  ? acpi_terminate+0xa/0x14
+>[    0.538701]  ? acpi_init+0x2af/0x34f
+>[    0.540008]  ? acpi_sleep_proc_init+0x27/0x27
+>[    0.541593]  ? do_one_initcall+0x4e/0x1a0
+>[    0.543008]  ? kernel_init_freeable+0x19e/0x21f
+>[    0.546202]  ? rest_init+0x80/0x80
+>[    0.547513]  ? kernel_init+0xa/0x100
+>[    0.548817]  ? ret_from_fork+0x25/0x30
+>[    0.550587] vgaarb: loaded
+>[    0.551716] EDAC MC: Ver: 3.0.0
+>[    0.553744] PCI: Probing PCI hardware
+>[    0.555038] PCI host bridge to bus 0000:00
+> ... Continue to boot and log is omitted ...
+
+I analyzed this memory leak in detail and found acpi_ns_evaluate() function
+only removes info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors
+occur, the status value is not AE_CTRL_RETURN_VALUE, and info->return_object is
+also not null. 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 <kkamagui@gmail.com>
+---
+ drivers/acpi/acpica/nseval.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
+index d22167c..f13d3cf 100644
+--- a/drivers/acpi/acpica/nseval.c
++++ b/drivers/acpi/acpica/nseval.c
+@@ -308,6 +308,14 @@ acpi_status acpi_ns_evaluate(struct acpi_evaluate_info *info)
+ 		/* Map AE_CTRL_RETURN_VALUE to AE_OK, we are done with it */
+ 
+ 		status = AE_OK;
++	} else if (ACPI_FAILURE(status)) {
++
++		/* If return_object exists, delete it */
++
++		if (info->return_object) {
++			acpi_ut_remove_reference(info->return_object);
++			info->return_object = NULL;
++		}
+ 	}
+ 
+ 	ACPI_DEBUG_PRINT((ACPI_DB_NAMES,
diff --git a/freed-ora/current/f25/iio-race-fix.patch b/freed-ora/current/f25/iio-race-fix.patch
deleted file mode 100644
index 2661fa535..000000000
--- a/freed-ora/current/f25/iio-race-fix.patch
+++ /dev/null
@@ -1,83 +0,0 @@
-From eafad73ed3851707fa6e3124a255fc049ff9545d Mon Sep 17 00:00:00 2001
-From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
-Date: Sat, 12 Aug 2017 09:09:21 -0700
-Subject: iio: hid-sensor-trigger: Fix the race with user space powering up
- sensors
-
-It has been reported for a while that with iio-sensor-proxy service the
-rotation only works after one suspend/resume cycle. This required a wait
-in the systemd unit file to avoid race. I found a Yoga 900 where I could
-reproduce this.
-
-The problem scenerio is:
-- During sensor driver init, enable run time PM and also set a
-  auto-suspend for 3 seconds.
-	This result in one runtime resume. But there is a check to avoid
-a powerup in this sequence, but rpm is active
-- User space iio-sensor-proxy tries to power up the sensor. Since rpm is
-  active it will simply return. But sensors were not actually
-powered up in the prior sequence, so actaully the sensors will not work
-- After 3 seconds the auto suspend kicks
-
-If we add a wait in systemd service file to fire iio-sensor-proxy after
-3 seconds, then now everything will work as the runtime resume will
-actually powerup the sensor as this is a user request.
-
-To avoid this:
-- Remove the check to match user requested state, this will cause a
-  brief powerup, but if the iio-sensor-proxy starts immediately it will
-still work as the sensors are ON.
-- Also move the autosuspend delay to place when user requested turn off
-  of sensors, like after user finished raw read or buffer disable
-
-Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
-Tested-by: Bastien Nocera <hadess@hadess.net>
-Cc: <Stable@vger.kernel.org>
-Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
----
- drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 8 ++++----
- 1 file changed, 4 insertions(+), 4 deletions(-)
-
-diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
-index 16ade0a..0e4b379 100644
---- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
-+++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
-@@ -111,8 +111,6 @@ static int _hid_sensor_power_state(struct hid_sensor_common *st, bool state)
- 	s32 poll_value = 0;
- 
- 	if (state) {
--		if (!atomic_read(&st->user_requested_state))
--			return 0;
- 		if (sensor_hub_device_open(st->hsdev))
- 			return -EIO;
- 
-@@ -161,6 +159,9 @@ static int _hid_sensor_power_state(struct hid_sensor_common *st, bool state)
- 				       &report_val);
- 	}
- 
-+	pr_debug("HID_SENSOR %s set power_state %d report_state %d\n",
-+		 st->pdev->name, state_val, report_val);
-+
- 	sensor_hub_get_feature(st->hsdev, st->power_state.report_id,
- 			       st->power_state.index,
- 			       sizeof(state_val), &state_val);
-@@ -182,6 +183,7 @@ int hid_sensor_power_state(struct hid_sensor_common *st, bool state)
- 		ret = pm_runtime_get_sync(&st->pdev->dev);
- 	else {
- 		pm_runtime_mark_last_busy(&st->pdev->dev);
-+		pm_runtime_use_autosuspend(&st->pdev->dev);
- 		ret = pm_runtime_put_autosuspend(&st->pdev->dev);
- 	}
- 	if (ret < 0) {
-@@ -285,8 +287,6 @@ int hid_sensor_setup_trigger(struct iio_dev *indio_dev, const char *name,
- 	/* Default to 3 seconds, but can be changed from sysfs */
- 	pm_runtime_set_autosuspend_delay(&attrb->pdev->dev,
- 					 3000);
--	pm_runtime_use_autosuspend(&attrb->pdev->dev);
--
- 	return ret;
- error_unreg_trigger:
- 	iio_trigger_unregister(trig);
--- 
-cgit v1.1
-
diff --git a/freed-ora/current/f25/kernel.spec b/freed-ora/current/f25/kernel.spec
index 3d14ce551..e174ba377 100644
--- a/freed-ora/current/f25/kernel.spec
+++ b/freed-ora/current/f25/kernel.spec
@@ -92,7 +92,7 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}
 
 # Do we have a -stable update to apply?
-%define stable_update 9
+%define stable_update 11
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@@ -717,9 +717,6 @@ Patch704: input-rmi4-remove-the-need-for-artifical-IRQ.patch
 # rhbz 1476467
 Patch706: Fix-for-module-sig-verification.patch
 
-# request for bug fix
-Patch709: iio-race-fix.patch
-
 # rhbz 1485086
 Patch710: pci-mark-amd-stoney-gpu-ats-as-broken.patch
 
@@ -729,6 +726,21 @@ Patch711: rt2800-fix-TX_PIN_CFG-setting-for-non-MT7620-chips.patch
 # CVE-2017-7558 rhbz 1480266 1484810
 Patch712: net-sctp-Avoid-out-of-bounds-reads-from-address-storage.patch
 
+# CVE-2017-13693 rhbz 1485346 1485356
+Patch713: acpi-acpica-fix-acpi-operand-cache-leak-in-dsutils.c.patch
+
+# CVE-2017-13694 rhbz 1485348
+Patch714: V4-acpi-acpica-fix-acpi-parse-and-parseext-cache-leaks.patch
+
+# CVE-2017-13695 rhbz 1485349
+Patch715: acpi-acpica-fix-acpi-operand-cache-leak-in-nseval.c.patch
+
+# rhbz 1484587
+Patch716: md-raid-reset-bio-allocated-from-mempool.patch
+
+# CVE-2017-14051 rhbz 1487126 1487127
+Patch717: v2-scsi-qla2xxx-Fix-an-integer-overflow-in-sysfs-code.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -2399,6 +2411,22 @@ fi
 #
 #
 %changelog
+* Fri Sep  8 2017 Alexandre Oliva <lxoliva@fsfla.org> -libre
+- GNU Linux-libre 4.12.11-gnu.
+
+* Thu Sep 07 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.12.11-200
+- Linux v4.12.11
+
+* Thu Aug 31 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.12.10-200
+- Fix CVE-2017-14051 (rhbz 1487126 1487127)
+
+* Wed Aug 30 2017 Justin M. Forbes <jforbes@redhat.com>
+- Linux v4.12.10
+- Fix for CVE-2017-13693 (rhbz 1485346 1485356)
+- Fix for CVE-2017-13694 (rhbz 1485348)
+- Fix for CVE-2017-13695 (rhbz 1485349)
+- Fix for raid 1/10 (rhbz 1484587)
+
 * Fri Aug 25 2017 Alexandre Oliva <lxoliva@fsfla.org> -libre
 - GNU Linux-libre 4.12.9-gnu.
 
diff --git a/freed-ora/current/f25/md-raid-reset-bio-allocated-from-mempool.patch b/freed-ora/current/f25/md-raid-reset-bio-allocated-from-mempool.patch
new file mode 100644
index 000000000..b3a73354f
--- /dev/null
+++ b/freed-ora/current/f25/md-raid-reset-bio-allocated-from-mempool.patch
@@ -0,0 +1,132 @@
+From:       Shaohua Li <shli@kernel.org>
+Date:       2017-08-25 2:41:16
+Subject:    [PATCH] md/raid1/10: reset bio allocated from mempool
+
+From: Shaohua Li <shli@fb.com>
+
+Data allocated from mempool doesn't always get initialized, this happens when
+the data is reused instead of fresh allocation. In the raid1/10 case, we must
+reinitialize the bios.
+
+Reported-by: Jonathan G. Underwood <jonathan.underwood@gmail.com>
+Fixes: f0250618361d(md: raid10: don't use bio's vec table to manage resync pages)
+Fixes: 98d30c5812c3(md: raid1: don't use bio's vec table to manage resync pages)
+Cc: stable@vger.kernel.org (4.12+)
+Cc: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+---
+ drivers/md/raid1.c  | 19 ++++++++++++++++++-
+ drivers/md/raid10.c | 35 ++++++++++++++++++++++++++++++++---
+ 2 files changed, 50 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
+index f50958ded9f0..79474f47eeef 100644
+--- a/drivers/md/raid1.c
++++ b/drivers/md/raid1.c
+@@ -2564,6 +2564,23 @@ static int init_resync(struct r1conf *conf)
+ 	return 0;
+ }
+ 
++static struct r1bio *raid1_alloc_init_r1buf(struct r1conf *conf)
++{
++	struct r1bio *r1bio = mempool_alloc(conf->r1buf_pool, GFP_NOIO);
++	struct resync_pages *rps;
++	struct bio *bio;
++	int i;
++
++	for (i = conf->poolinfo->raid_disks; i--; ) {
++		bio = r1bio->bios[i];
++		rps = bio->bi_private;
++		bio_reset(bio);
++		bio->bi_private = rps;
++	}
++	r1bio->master_bio = NULL;
++	return r1bio;
++}
++
+ /*
+  * perform a "sync" on one "block"
+  *
+@@ -2649,7 +2666,7 @@ static sector_t raid1_sync_request(struct mddev *mddev, sector_t sector_nr,
+ 
+ 	bitmap_cond_end_sync(mddev->bitmap, sector_nr,
+ 		mddev_is_clustered(mddev) && (sector_nr + 2 * RESYNC_SECTORS > conf->cluster_sync_high));
+-	r1_bio = mempool_alloc(conf->r1buf_pool, GFP_NOIO);
++	r1_bio = raid1_alloc_init_r1buf(conf);
+ 
+ 	raise_barrier(conf, sector_nr);
+ 
+diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
+index f55d4cc085f6..d51ac02e98ef 100644
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -2798,6 +2798,35 @@ static int init_resync(struct r10conf *conf)
+ 	return 0;
+ }
+ 
++static struct r10bio *raid10_alloc_init_r10buf(struct r10conf *conf)
++{
++	struct r10bio *r10bio = mempool_alloc(conf->r10buf_pool, GFP_NOIO);
++	struct rsync_pages *rp;
++	struct bio *bio;
++	int nalloc;
++	int i;
++
++	if (test_bit(MD_RECOVERY_SYNC, &conf->mddev->recovery) ||
++	    test_bit(MD_RECOVERY_RESHAPE, &conf->mddev->recovery))
++		nalloc = conf->copies; /* resync */
++	else
++		nalloc = 2; /* recovery */
++
++	for (i = 0; i < nalloc; i++) {
++		bio = r10bio->devs[i].bio;
++		rp = bio->bi_private;
++		bio_reset(bio);
++		bio->bi_private = rp;
++		bio = r10bio->devs[i].repl_bio;
++		if (bio) {
++			rp = bio->bi_private;
++			bio_reset(bio);
++			bio->bi_private = rp;
++		}
++	}
++	return r10bio;
++}
++
+ /*
+  * perform a "sync" on one "block"
+  *
+@@ -3027,7 +3056,7 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr,
+ 				atomic_inc(&mreplace->nr_pending);
+ 			rcu_read_unlock();
+ 
+-			r10_bio = mempool_alloc(conf->r10buf_pool, GFP_NOIO);
++			r10_bio = raid10_alloc_init_r10buf(conf);
+ 			r10_bio->state = 0;
+ 			raise_barrier(conf, rb2 != NULL);
+ 			atomic_set(&r10_bio->remaining, 0);
+@@ -3236,7 +3265,7 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr,
+ 		}
+ 		if (sync_blocks < max_sync)
+ 			max_sync = sync_blocks;
+-		r10_bio = mempool_alloc(conf->r10buf_pool, GFP_NOIO);
++		r10_bio = raid10_alloc_init_r10buf(conf);
+ 		r10_bio->state = 0;
+ 
+ 		r10_bio->mddev = mddev;
+@@ -4360,7 +4389,7 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr,
+ 
+ read_more:
+ 	/* Now schedule reads for blocks from sector_nr to last */
+-	r10_bio = mempool_alloc(conf->r10buf_pool, GFP_NOIO);
++	r10_bio = raid10_alloc_init_r10buf(conf);
+ 	r10_bio->state = 0;
+ 	raise_barrier(conf, sectors_done != 0);
+ 	atomic_set(&r10_bio->remaining, 0);
+-- 
+2.11.0
+
+--
+To unsubscribe from this list: send the line "unsubscribe linux-raid" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/freed-ora/current/f25/patch-4.12-gnu-4.12.11-gnu.xz.sign b/freed-ora/current/f25/patch-4.12-gnu-4.12.11-gnu.xz.sign
new file mode 100644
index 000000000..bcee6a2e4
--- /dev/null
+++ b/freed-ora/current/f25/patch-4.12-gnu-4.12.11-gnu.xz.sign
@@ -0,0 +1,6 @@
+-----BEGIN PGP SIGNATURE-----
+
+iF0EABECAB0WIQRHRALIxYLa++OJxCe8t8+Hfn1HpwUCWbIyQAAKCRC8t8+Hfn1H
+pzwNAJsEdC7QCHHvGQI/Cm9FvRT3UspplwCgnlrX5XbujXZLTA1ipZ+Hkz+l5DI=
+=H183
+-----END PGP SIGNATURE-----
diff --git a/freed-ora/current/f25/patch-4.12-gnu-4.12.9-gnu.xz.sign b/freed-ora/current/f25/patch-4.12-gnu-4.12.9-gnu.xz.sign
deleted file mode 100644
index dbcd980b3..000000000
--- a/freed-ora/current/f25/patch-4.12-gnu-4.12.9-gnu.xz.sign
+++ /dev/null
@@ -1,6 +0,0 @@
------BEGIN PGP SIGNATURE-----
-
-iF0EABECAB0WIQRHRALIxYLa++OJxCe8t8+Hfn1HpwUCWaAxQAAKCRC8t8+Hfn1H
-p8XWAJ9V59PVbR7olWwTjGewSxKyFkaN3gCgj5LDy4UHLsqog8GvnjJj8NLxJjI=
-=OOqK
------END PGP SIGNATURE-----
diff --git a/freed-ora/current/f25/sources b/freed-ora/current/f25/sources
index 2ec4451e2..6619ce8b5 100644
--- a/freed-ora/current/f25/sources
+++ b/freed-ora/current/f25/sources
@@ -1,3 +1,3 @@
 SHA512 (linux-libre-4.12-gnu.tar.xz) = d5586dba2e4deeb42ffe98c9305111da56e0741bb4508642d103367a0ef712c837e160366c3656d18f0d636fcd5b60c27593cb9216e10025d6abc74e6cdb05e4
 SHA512 (perf-man-4.12.tar.gz) = 4d3bbda1f520dba0007c351af46f45085fe4842074eb2e01aee736fd369df595f8f72ed6c1192715f1120bf3353279777f9dca1178fe93bffe5be2de700d409c
-SHA512 (patch-4.12-gnu-4.12.9-gnu.xz) = 1c8ede75976fc9cfe3ea189c24f1ffd7e4648705297ac34781333b3e3a274c3fac979636abfc147e7cdef764ae2bb9275c4313480bc6ad3d73c57138d14c611f
+SHA512 (patch-4.12-gnu-4.12.11-gnu.xz) = 6ebb1636838cd5d5b96f669cf06d69ee6938be6dc9818a5a430e35bf579b956adba49907e273c5ab3c388c5181fa9d09a9a0e99a272cd649417f29fb888b797f
diff --git a/freed-ora/current/f25/v2-scsi-qla2xxx-Fix-an-integer-overflow-in-sysfs-code.patch b/freed-ora/current/f25/v2-scsi-qla2xxx-Fix-an-integer-overflow-in-sysfs-code.patch
new file mode 100644
index 000000000..6850c0ca2
--- /dev/null
+++ b/freed-ora/current/f25/v2-scsi-qla2xxx-Fix-an-integer-overflow-in-sysfs-code.patch
@@ -0,0 +1,67 @@
+From patchwork Wed Aug 30 13:30:35 2017
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: [v2] scsi: qla2xxx: Fix an integer overflow in sysfs code
+From: Dan Carpenter <dan.carpenter@oracle.com>
+X-Patchwork-Id: 9929625
+Message-Id: <20170830133035.nbkiled5hhdt26ui@mwanda>
+To: qla2xxx-upstream@qlogic.com, shqking <shqking@gmail.com>,
+ Joe Carnuccio <joe.carnuccio@qlogic.com>
+Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
+ "Martin K. Petersen" <martin.petersen@oracle.com>,
+ linux-scsi@vger.kernel.org, security@kernel.org
+Date: Wed, 30 Aug 2017 16:30:35 +0300
+
+The value of "size" comes from the user.  When we add "start + size"
+it could lead to an integer overflow bug.
+
+It means we vmalloc() a lot more memory than we had intended.  I believe
+that on 64 bit systems vmalloc() can succeed even if we ask it to
+allocate huge 4GB buffers.  So we would get memory corruption and likely
+a crash when we call ha->isp_ops->write_optrom() and ->read_optrom().
+
+Only root can trigger this bug.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=194061
+
+Cc: stable@vger.kernel.org
+Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.")
+Reported-by: shqking <shqking@gmail.com>
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+---
+v2: Add stable and the URL for bugzila
+
+diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
+index 75c4b312645e..9ce28c4f9812 100644
+--- a/drivers/scsi/qla2xxx/qla_attr.c
++++ b/drivers/scsi/qla2xxx/qla_attr.c
+@@ -318,6 +318,8 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct kobject *kobj,
+ 		return -EINVAL;
+ 	if (start > ha->optrom_size)
+ 		return -EINVAL;
++	if (size > ha->optrom_size - start)
++		size = ha->optrom_size - start;
+ 
+ 	mutex_lock(&ha->optrom_mutex);
+ 	switch (val) {
+@@ -343,8 +345,7 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct kobject *kobj,
+ 		}
+ 
+ 		ha->optrom_region_start = start;
+-		ha->optrom_region_size = start + size > ha->optrom_size ?
+-		    ha->optrom_size - start : size;
++		ha->optrom_region_size = start + size;
+ 
+ 		ha->optrom_state = QLA_SREADING;
+ 		ha->optrom_buffer = vmalloc(ha->optrom_region_size);
+@@ -417,8 +418,7 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct kobject *kobj,
+ 		}
+ 
+ 		ha->optrom_region_start = start;
+-		ha->optrom_region_size = start + size > ha->optrom_size ?
+-		    ha->optrom_size - start : size;
++		ha->optrom_region_size = start + size;
+ 
+ 		ha->optrom_state = QLA_SWRITING;
+ 		ha->optrom_buffer = vmalloc(ha->optrom_region_size);