| Message ID | 20240627085601.24321-1-jan@mwa.re |
|---|---|
| State | Rejected |
| Headers | show |
| Series | ext4: fix kernel segfault after iterator overflow | expand |
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
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 &&
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(-)