[PATCH] ext4: fix kernel segfault after iterator overflow

[PATCH] ext4: fix kernel segfault after iterator overflow

[Jan Henrik Weinstock]

When search_buf gets placed at the end of the virtual address space
        de = (struct ext4_dir_entry_2 *) ((char *) de + de_len);
might overflow to zero and a subsequent loop iteration will crash.

Observed on a simulated riscv32 system using 2GB of memory and a rootfs
on MMC.

Signed-off-by: Jan Henrik Weinstock <jan@mwa.re>
---
 fs/ext4/namei.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index a630b27a4..030a11412 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1537,7 +1537,8 @@ int ext4_search_dir(struct buffer_head *bh, char *search_buf, int buf_size,
 
 	de = (struct ext4_dir_entry_2 *)search_buf;
 	dlimit = search_buf + buf_size;
-	while ((char *) de < dlimit - EXT4_BASE_DIR_LEN) {
+	while ((char *) de < dlimit - EXT4_BASE_DIR_LEN &&
+	       (char *) de >= search_buf) {
 		/* this code is executed quadratically often */
 		/* do minimal checking `by hand' */
 		if (de->name + de->name_len <= dlimit &&
-- 
2.45.2

Re: [PATCH] ext4: fix kernel segfault after iterator overflow

[Theodore Ts'o]

On Thu, Jun 27, 2024 at 10:56:01AM +0200, Jan Henrik Weinstock wrote:
> When search_buf gets placed at the end of the virtual address space
>         de = (struct ext4_dir_entry_2 *) ((char *) de + de_len);
> might overflow to zero and a subsequent loop iteration will crash.
> 
> Observed on a simulated riscv32 system using 2GB of memory and a rootfs
> on MMC.
> 
> Signed-off-by: Jan Henrik Weinstock <jan@mwa.re>

This is discussed earlier and the conclusion that it is a bug that on
RiscV architectures the kernel can hand out the last 4k page in the 
address space.  As Al Viro pointed out on this thread[1]:

>On Sat, Apr 13, 2024 at 07:46:03PM -0600, Andreas Dilger wrote:
>>
>> As to whether the 0xfffff000 address itself is valid for riscv32 is
>> outside my realm, but given that RAM is cheap it doesn't seem unlikely
>> to have 4GB+ of RAM and want to use it all.  The riscv32 might consider
>> reserving this page address from allocation to avoid similar issues in
>> other parts of the code, as is done with the NULL/0 page address.
>
>Not a chance.  *Any* page mapped there is a serious bug on any 32bit
>box.  Recall what ERR_PTR() is...
>
>On any architecture the virtual addresses in range (unsigned long)-512..
>(unsigned long)-1 must never resolve to valid kernel objects.
>In other words, any kind of wraparound here is asking for an oops on
>attempts to access the elements of buffer - kernel dereference of
>(char *)0xfffff000 on a 32bit box is already a bug.

[1] https://lore.kernel.org/all/878r1ibpdn.fsf@all.your.base.are.belong.to.us/

In any case, if on the RiscV platform the mm layer hands out a page at
the very end of the address space, there will be **all** sorts of
failures, not just in this particular ext4 codepath.  So this needs to
be fixed for RiscV in the mm layer.

Cheers,

					- Ted