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>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Apr 2024 12:29:43 +0200
From: Nam Cao <namcao@...utronix.de>
To: Mike Rapoport <rppt@...nel.org>,
	Andreas Dilger <adilger@...ger.ca>,
	Björn Töpel <bjorn@...nel.org>,
	linux-riscv@...ts.infradead.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"ndesaulniers @ google . com" <ndesaulniers@...gle.com>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	Tejun Heo <tj@...nel.org>,
	Krister Johansen <kjlx@...pleofstupid.com>,
	Changbin Du <changbin.du@...wei.com>,
	Arnd Bergmann <arnd@...db.de>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	linux-kernel@...r.kernel.org
Cc: Nam Cao <namcao@...utronix.de>,
	stable@...r.kernel.org
Subject: [PATCH] init: fix allocated page overlapping with PTR_ERR

There is nothing preventing kernel memory allocators from allocating a
page that overlaps with PTR_ERR(), except for architecture-specific
code that setup memblock.

It was discovered that RISCV architecture doesn't setup memblock
corectly, leading to a page overlapping with PTR_ERR() being allocated,
and subsequently crashing the kernel (link in Close: )

The reported crash has nothing to do with PTR_ERR(): the last page
(at address 0xfffff000) being allocated leads to an unexpected
arithmetic overflow in ext4; but still, this page shouldn't be
allocated in the first place.

Because PTR_ERR() is an architecture-independent thing, we shouldn't
ask every single architecture to set this up. There may be other
architectures beside RISCV that have the same problem.

Fix this one and for all by reserving the physical memory page that
may be mapped to the last virtual memory page as part of low memory.

Unfortunately, this means if there is actual memory at this reserved
location, that memory will become inaccessible. However, if this page
is not reserved, it can only be accessed as high memory, so this
doesn't matter if high memory is not supported. Even if high memory is
supported, it is still only one page.

Closes: https://lore.kernel.org/linux-riscv/878r1ibpdn.fsf@all.your.base.are.belong.to.us
Signed-off-by: Nam Cao <namcao@...utronix.de>
Cc: <stable@...r.kernel.org> # all versions
---
 init/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/init/main.c b/init/main.c
index 881f6230ee59..f8d2793c4641 100644
--- a/init/main.c
+++ b/init/main.c
@@ -900,6 +900,7 @@ void start_kernel(void)
 	page_address_init();
 	pr_notice("%s", linux_banner);
 	early_security_init();
+	memblock_reserve(__pa(-PAGE_SIZE), PAGE_SIZE); /* reserve last page for ERR_PTR */
 	setup_arch(&command_line);
 	setup_boot_config();
 	setup_command_line(command_line);
-- 
2.39.2


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ