From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A0EA2746A for ; Tue, 23 Sep 2025 02:21:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758594068; cv=none; b=pYDCq0+vq41ZbjxYT8nYtxfkI5p4Resd33J2BOmQhcs0q4J7kNJnmgI4qsRWxdmiMoGfQMnXTnlfF0OVuGxZX1PAyXVHJWWLsJSe3JoYyF2XcBbCyf2aQ/KI0ZrR5YG0ldmeY7Qnrim1DXR0VyPshNrEdD+dEWS6K/kRWKz3C88= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758594068; c=relaxed/simple; bh=0hXC7tPYAh+1iRQxPqrJA311n1IPVWOkt0Jji5o5zgY=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=hF8sRYtAmsR4ceKfnXilk+K/i8RpY9jwznPRmPH5/mj5XFH33UwUMH/yRQcwGWHjuK0miRHc9WRuMOHqth0QQ9dqVn9Y3XRFY3TIbApNjfOSlXnQlZVUPIoI3VB2qY+cVhUomlYK2bRb0w1EDKjg4V3ZNhkK6lwvz5hGZLOgtEU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tPLe37hy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tPLe37hy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 249D5C4CEF0; Tue, 23 Sep 2025 02:21:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758594068; bh=0hXC7tPYAh+1iRQxPqrJA311n1IPVWOkt0Jji5o5zgY=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=tPLe37hyszN/6vsShhItZIqV9Rha/mmdWznfuahzt0G7DnP90pFxgk7t+Nys4I9uD EzIAGy+cu+mbWAlhT0+BGf1hkIgQbIpGtePC8YWgcZxxnlK4MfzN14bqyAOUpiQmAF HvhJSMPD6FSc5W5FbbBtjHTdaIFOwC1cF8Ecf5Gv5dRYIPNFxs0aysmPYnt78F7lwo 9d74wARbt2bQCXKOB46dqccJQstQkxQ9qo0tPWzCxCe6dhhCjLfRYeOrwI3uZr0oMT szBn8c6NNSJH1XkRRs2Bz1GlWunFMROhFesHFEzX6nKjRWO2wxNbLoyG0yvAe+bBHr 1ikGQPZSG0bpA== Message-ID: <338fd84f-80fd-4ec7-b87e-64e76015b8f4@kernel.org> Date: Tue, 23 Sep 2025 10:21:05 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, LKML , syzbot+1a9af3ef3c84c5e14dcc@syzkaller.appspotmail.com Subject: Re: [PATCH] erofs: avoid reading more for fragment maps To: Gao Xiang , linux-erofs@lists.ozlabs.org References: <68c8583d.050a0220.2ff435.03a3.GAE@google.com> <20250916084851.1759111-1-hsiangkao@linux.alibaba.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20250916084851.1759111-1-hsiangkao@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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@syzkaller.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 Reviewed-by: Chao Yu Thanks,