lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Mon, 11 Feb 2013 13:01:15 -0700
From:	T Makphaibulchoke <tmac@...com>
To:	matt.fleming@...el.com, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com, x86@...nel.org, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc:	T Makphaibulchoke <tmac@...com>
Subject: [PATCH v2] x86/platform/efi/efi_64.c: fix a possible hang in efi_ioremap when init_memory_mapping fails.

An attempt to recursively invoke efi_ioremap may cause the kernel to get stuck in an infinite recursive loop.
Calling efi_ioremap with non-page aligned size will eventually, due to
its recursive implementation, call itself with size smaller than a page.
In this case, init_memory_mapping will fail, returning a NULL.
An attempt to recursively invoke efi_ioremap, without checking for a failure,
results in a recursive mapping of an invalid physical address range, 0 to size +
physaddr, causing the kernel to get stuck in an infinite recursive loop.

Here is an example of a hang in the efi_ioremap recursive loop with
efi_ioremap(0x3ff000, 0xfff) call,

[   69.266517] init_memory_mapping: [mem 0x003ff000-0x003ffffe]
[   69.267787] init_memory_mapping: [mem 0x00000000-0x003ffffe]
[   69.268222]  [mem 0x00000000-0x001fffff] page 2M
[   69.268580]  [mem 0x00200000-0x003fefff] page 4k
[   69.268953] init_memory_mapping: [mem 0x003ff000-0x003ffffe]
[   69.270216] init_memory_mapping: [mem 0x00000000-0x003ffffe]
[   69.270651]  [mem 0x00000000-0x001fffff] page 2M
[   69.271016]  [mem 0x00200000-0x003fefff] page 4k

Signed-off-by: T Makphaibulchoke <tmac@...com>
---
 arch/x86/platform/efi/efi_64.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 2b20038..4b3e2b0 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -102,6 +102,12 @@ void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
 		return ioremap(phys_addr, size);
 
 	last_map_pfn = init_memory_mapping(phys_addr, phys_addr + size);
+
+	if (!last_map_pfn) {
+		/* Do not try to rmmap again in case of a failure */
+		return NULL;
+	}
+
 	if ((last_map_pfn << PAGE_SHIFT) < phys_addr + size) {
 		unsigned long top = last_map_pfn << PAGE_SHIFT;
 		efi_ioremap(top, size - (top - phys_addr), type, attribute);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ