[PATCH] erofs: Prohibit access to excessive algorithmformat

Edward Adam Davis posted 1 patch 1 month, 1 week ago
fs/erofs/zdata.c | 5 +++++
1 file changed, 5 insertions(+)
[PATCH] erofs: Prohibit access to excessive algorithmformat
Posted by Edward Adam Davis 1 month, 1 week ago
syz reported a global-out-of-bounds Read in z_erofs_decompress_queue.

OOB occurs in z_erofs_decompress_queue() because algorithmformat is too
large.

Added relevant checks when registering pcluster.

Reported-by: syzbot+5a398eb460ddaa6f242f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5a398eb460ddaa6f242f
Tested-by: syzbot+5a398eb460ddaa6f242f@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/erofs/zdata.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
index 2d73297003d2..085fa0685a57 100644
--- a/fs/erofs/zdata.c
+++ b/fs/erofs/zdata.c
@@ -762,6 +762,10 @@ static int z_erofs_register_pcluster(struct z_erofs_frontend *fe)
 	pcl->from_meta = map->m_flags & EROFS_MAP_META;
 	fe->mode = Z_EROFS_PCLUSTER_FOLLOWED;
 
+	if (pcl->algorithmformat >= Z_EROFS_COMPRESSION_MAX) {
+		err = -EINVAL;
+		goto out;
+	}
 	/*
 	 * lock all primary followed works before visible to others
 	 * and mutex_trylock *never* fails for a new pcluster.
@@ -796,6 +800,7 @@ static int z_erofs_register_pcluster(struct z_erofs_frontend *fe)
 
 err_out:
 	mutex_unlock(&pcl->lock);
+out:
 	z_erofs_free_pcluster(pcl);
 	return err;
 }
-- 
2.43.0
Re: [PATCH] erofs: Prohibit access to excessive algorithmformat
Posted by Gao Xiang 1 month, 1 week ago
Hi,

On 2025/8/23 09:53, Edward Adam Davis wrote:
> syz reported a global-out-of-bounds Read in z_erofs_decompress_queue.
> 
> OOB occurs in z_erofs_decompress_queue() because algorithmformat is too
> large.
> 
> Added relevant checks when registering pcluster.
> 
> Reported-by: syzbot+5a398eb460ddaa6f242f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=5a398eb460ddaa6f242f
> Tested-by: syzbot+5a398eb460ddaa6f242f@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>

Your analysis is correct, but the fix should be applied to zmap.c
instead since it parses the on-disk map format. Also, it's actually
a regression out of new encoded extents since the old compress
indexes already has the check.

I've submitted a formal fix:
https://lore.kernel.org/r/20250823093018.3117864-1-hsiangkao@linux.alibaba.com

Thanks,
Gao Xiang