From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) (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 E02293019A9; Thu, 9 Apr 2026 12:14:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775736899; cv=none; b=QKI0DO97mi3UFzDZZY4qE2bMLha8tzWxYN/s06YccPl+4kap8u+41EK7Y0Ga0V0p9p2K3UKNFrKD2+74YsE+8X8euJ8i948ThRrUqx1Pjxvu42c5X/4XQQNHFegs1iqwmhLYFA0dzP5MYSd6AoiP2cotUwkHAiy62Rx4U54EaOM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775736899; c=relaxed/simple; bh=SWg8DKhVcl43so8mnnHDhT+ciypgKIMxPg31VgMQprg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UZH/250VjRUiXcKism5wWGfqxllxCkNtPgSfTATUJPYuFLbyvQuvJrXmszw4r2ZpR/Cg4rbYbEBXEAkCdg2Zf79e89iiJeBIKD1V+VfUIs+DJ8k4GJWPoXKOPZarkYiXwbA5YPdKajcd9At7ny9jM154PZFTNdSssiHs32ZMzbo= 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=eP1+KH5j; arc=none smtp.client-ip=115.124.30.99 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="eP1+KH5j" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1775736891; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=QsBZlsOs/aPVR09Nx2+/RG2UPFE2Ga7fdOknV0byQxw=; b=eP1+KH5jV31zS+eSbnzS4RcnTGeqTp2oqQvq1pf5h0KSLwBPhtZ+yS17tLnrMTbMmK6pemwo9ivibSNQKS5Nya57GhcJC2v6i9Ug0AiOh1va1qE7SkpIi7e6LRY17wCWmJ9e+iIOvN3aKWzOjSWu6Wy6NsO38PC6dCy3pUD7R6A= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0X0iI0If_1775736888; Received: from 30.41.54.139(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X0iI0If_1775736888 cluster:ay36) by smtp.aliyun-inc.com; Thu, 09 Apr 2026 20:14:50 +0800 Message-ID: <17f2ec58-e8ec-4f59-9e8f-0e88bde7d98b@linux.alibaba.com> Date: Thu, 9 Apr 2026 20:14:46 +0800 Precedence: bulk X-Mailing-List: stable@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> <1922A494-0E56-4E11-9D3E-3604BCBE33AD@outlook.com> From: Gao Xiang In-Reply-To: <1922A494-0E56-4E11-9D3E-3604BCBE33AD@outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/4/9 19:49, Junrui Luo wrote: > On Thu, Apr 09, 2026 at 06:56:42PM +0800, Gao Xiang wrote: >> Can you share your initial crafted image binary >> with `gzip -9 | base64` encoding here? > > $ gzip -9 < /tmp/erofs-test/test.erofs | base64 > H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+gdilS > Jo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9iPNtbjhan > 04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz2DF/21+20T/l > dgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1wywAAAAAAAADwu14A > TsEYtgBQAAA= > > In QEMU: > $ mount -t erofs -o cache_strategy=disabled test.erofs /mnt > $ dd if=/mnt/data of=/dev/null bs=4096 count=1 > >> I think the proper place to fix this is in >> z_erofs_map_sanity_check(). > > I will resend with the check in > z_erofs_map_sanity_check() instead if the reproducer is acceptable. It's not a very trivial fix without having some more understanding of EROFS compression codebase, I will add your `Repored-by:` and try to tidy up the related code. Thanks, Gao Xiang > > Thanks, > Junrui Luo