linux-kernel - [PATCH v2] x86/platform/efi/efi_64.c: fix a possible hang in efi_ioremap when init_memory

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]

Message-Id: <1360612875-16952-1-git-send-email-tmac@hp.com>
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/