From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (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 0B9FB3AEF5D; Thu, 9 Apr 2026 10:56:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775732211; cv=none; b=qvH5LNOJnCeJX5gGLZEXf1KNI1/Ex/c94s8EUmHEFL48hPOapncuhXSGiqb7TGqtZ3X7rsVH1QCmsBdQno4aTrSBd5zWZCWGsnwrrsufkaZcEFTXKkcc+55/iCpNcYJIQHnzwgS6rVSvB4MOnRFASJ4nFg5/ZkdPJ1Qti4HTp3s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775732211; c=relaxed/simple; bh=PmdelLBzfNDIWV+33epjCwYgz4N6+4c8k8arY9A+8AQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Foc5oM85LL2H9FIhueM1P6DbSzFnV/vcyYK3/XqUNkXyi1eRrGok/+gTChzw3y5+WgSXTyU+BwSjY/Jyyw/NBrdLqBGDsS3Fr5bBVIF27lpR5ixSHu7SIU1jUyvBGCGahwXjjKMrA26R1Dce68FCaNYvxQUAihky6/WM9Ps54Ls= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=t5HcD8Pr; arc=none smtp.client-ip=115.124.30.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="t5HcD8Pr" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1775732205; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=CBfTM9xBob73GimIL4JdnF/RxealF87d/9oNo4Ik0D0=; b=t5HcD8PrlntzUQ+yrydDhH3m7NfCndiYzB+tq8r6WoZwItMUEjpokvPjlAbOpK3qmpclMTWBu8+UaWQRVWvnHIsZAwhP8Z7oReA5tg6j1yKFWJIFRwJn2AKJTwEUXxJYoBk9hrn53amzg2kViKuAA1a4nK6sv1mB53LynfLwGDc= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0X0iBlhJ_1775732203; Received: from 30.41.54.139(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X0iBlhJ_1775732203 cluster:ay36) by smtp.aliyun-inc.com; Thu, 09 Apr 2026 18:56:45 +0800 Message-ID: Date: Thu, 9 Apr 2026 18:56:42 +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 Subject: Re: [PATCH] erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() To: Junrui Luo Cc: Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , "linux-erofs@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , Yuhao Jiang , "stable@vger.kernel.org" References: <31b4e893-44f4-49b4-935f-9cf37b5a0790@linux.alibaba.com> <3F909329-EB34-4B5E-A26D-081D9031DE01@outlook.com> From: Gao Xiang In-Reply-To: <3F909329-EB34-4B5E-A26D-081D9031DE01@outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/4/9 18:38, Junrui Luo wrote: > Hi Gao Xiang, > > Thank you for the review. > > On Thu, Apr 09, 2026 at 03:28:21PM +0800, Gao Xiang wrote: > >> For this kind of stuff, do you have a reproducer? > > I constructed a crafted EROFS image declaring plen=8192 and i_size=4096, giving > inpages=2 and outpages=1. Tested under QEMU with kernel (v7.0-rc6) plus a temporary > pr_warn trace in z_erofs_lz4_handle_overlap(): > > [ 12.889652] erofs: BOUNDARY CHECK: outpages=1 < inpages=2 > > The image mounts and the decompressor is reached with > partial_decoding=false and outpages < inpages. > >> I'm not sure what you're saying, but I don't think >> you really understand the entire logic. >> >> `m_la + m_llen` should not be page-aligned for typical >> erofs images, you can just mkfs.erofs -zlz4hc with some >> file and check it yourself. >> >> BTW, I just check upstream, and the inplace branch >> works prefectly. > > During testing I observed that the inplace branch was not entered with > my crafted image and incorrectly concluded it was structurally unreachable. > I apologize for the incorrect analysis. Can you share your initial crafted image binary with `gzip -9 | base64` encoding here? I think the proper place to fix this is in z_erofs_map_sanity_check(). But we only accept patches with proper reproducible ways (e.g. base64-encoded zipped images or syzbot link). Thanks, Gao Xiang