linux-kernel - Re: [PATCH] erofs: avoid reading more for fragment maps

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-prev] [day] [month] [year] [list]

Message-ID: <338fd84f-80fd-4ec7-b87e-64e76015b8f4@kernel.org>
Date: Tue, 23 Sep 2025 10:21:05 +0800
From: Chao Yu <chao@...nel.org>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>, linux-erofs@...ts.ozlabs.org
Cc: chao@...nel.org, LKML <linux-kernel@...r.kernel.org>,
 syzbot+1a9af3ef3c84c5e14dcc@...kaller.appspotmail.com
Subject: Re: [PATCH] erofs: avoid reading more for fragment maps

On 9/16/25 16:48, Gao Xiang wrote:
> Since all real encoded extents (directly handled by the decompression
> subsystem) have a sane, limited maximum decoded length
> (Z_EROFS_PCLUSTER_MAX_DSIZE), and the read‑more policy is only applied
> if needed.
> 
> However, it makes no sense to read more for non‑encoded maps, such as
> fragment extents, since such extents can be huge (up to i_size) and
> there is no benefit to reading more at this layer.
> 
> For normal images, it does not really matter, but for crafted images
> generated by syzbot, excessively large fragment extents can cause
> read‑more to run for an overly long time.
> 
> Reported-by: syzbot+1a9af3ef3c84c5e14dcc@...kaller.appspotmail.com
> Closes: https://lore.kernel.org/r/68c8583d.050a0220.2ff435.03a3.GAE@google.com
> Fixes: b44686c8391b ("erofs: fix large fragment handling")
> Fixes: b15b2e307c3a ("erofs: support on-disk compressed fragments data")
> Signed-off-by: Gao Xiang <hsiangkao@...ux.alibaba.com>

Reviewed-by: Chao Yu <chao@...nel.org>

Thanks,