linux-ext4 - Re: riscv32 EXT4 splat, 6.8 regression?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240416084417.569356d3@namcao>
Date: Tue, 16 Apr 2024 08:44:17 +0200
From: Nam Cao <namcao@...utronix.de>
To: Björn Töpel <bjorn@...nel.org>
Cc: Christian Brauner <brauner@...nel.org>, Andreas Dilger
 <adilger@...ger.ca>, Al Viro <viro@...iv.linux.org.uk>, linux-fsdevel
 <linux-fsdevel@...r.kernel.org>, Jan Kara <jack@...e.cz>, Linux Kernel
 Mailing List <linux-kernel@...r.kernel.org>,
 linux-riscv@...ts.infradead.org, Theodore Ts'o <tytso@....edu>, Ext4
 Developers List <linux-ext4@...r.kernel.org>, Conor Dooley
 <conor@...nel.org>, "Matthew Wilcox (Oracle)" <willy@...radead.org>, Anders
 Roxell <anders.roxell@...aro.org>
Subject: Re: riscv32 EXT4 splat, 6.8 regression?

On 2024-04-15 Björn Töpel wrote:
> Thanks for getting back! Spent some more time one it today.
> 
> It seems that the buddy allocator *can* return a page with a VA that can
> wrap (0xfffff000 -- pointed out by Nam and myself).
> 
> Further, it seems like riscv32 indeed inserts a page like that to the
> buddy allocator, when the memblock is free'd:
> 
>   | [<c024961c>] __free_one_page+0x2a4/0x3ea
>   | [<c024a448>] __free_pages_ok+0x158/0x3cc
>   | [<c024b1a4>] __free_pages_core+0xe8/0x12c
>   | [<c0c1435a>] memblock_free_pages+0x1a/0x22
>   | [<c0c17676>] memblock_free_all+0x1ee/0x278
>   | [<c0c050b0>] mem_init+0x10/0xa4
>   | [<c0c1447c>] mm_core_init+0x11a/0x2da
>   | [<c0c00bb6>] start_kernel+0x3c4/0x6de
> 
> Here, a page with VA 0xfffff000 is a added to the freelist. We were just
> lucky (unlucky?) that page was used for the page cache.

I just educated myself about memory mapping last night, so the below
may be complete nonsense. Take it with a grain of salt.

In riscv's setup_bootmem(), we have this line:
	max_low_pfn = max_pfn = PFN_DOWN(phys_ram_end);

I think this is the root cause: max_low_pfn indicates the last page
to be mapped. Problem is: nothing prevents PFN_DOWN(phys_ram_end) from
getting mapped to the last page (0xfffff000). If max_low_pfn is mapped
to the last page, we get the reported problem.

There seems to be some code to make sure the last page is not used
(the call to memblock_set_current_limit() right above this line). It is
unclear to me why this still lets the problem slip through.

The fix is simple: never let max_low_pfn gets mapped to the last page.
The below patch fixes the problem for me. But I am not entirely sure if
this is the correct fix, further investigation needed.

Best regards,
Nam

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index fa34cf55037b..17cab0a52726 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -251,7 +251,8 @@ static void __init setup_bootmem(void)
 	}

 	min_low_pfn = PFN_UP(phys_ram_base);
-	max_low_pfn = max_pfn = PFN_DOWN(phys_ram_end);
+	max_low_pfn = PFN_DOWN(memblock_get_current_limit());
+	max_pfn = PFN_DOWN(phys_ram_end);
 	high_memory = (void *)(__va(PFN_PHYS(max_low_pfn)));

 	dma32_phys_limit = min(4UL * SZ_1G, (unsigned long)PFN_PHYS(max_low_pfn));