From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) (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 20D3334AB1D; Thu, 9 Apr 2026 07:28:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.110 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775719714; cv=none; b=K83cEQDj67ZegtT0ZL02gh+8r2/7tGaA3JwNnWieAqBGb5xR2J/GsnDW72MZHG36CYOHXhjFg/pPoQKgSi3D+tDgBH4eXQgrkW+WS5uPu2uYeR1Mr61a9a4QTsiqobXJxoKZEAxmOxVPKCjsYj88NNQTTaPolBFxYlv+zhJsOik= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775719714; c=relaxed/simple; bh=T+NBLdVh9E+C14UHYRM9W0fnw2PgPYNp7mcnmntw9c8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L9ZkLEihO3PBl2rTn/nHVJ4odExZhKI/4Ziw9sUKwUWUzRtZ4Bj9zGU8mscTiCzXxlAjpUi7a6aiUvDD/wW2VVmpRF8fxrPFOhnOUZSc4kNvJ7H4f7EF+p5vN8SGshH+6x7DqRG6aIBGCBoXHPxIaWGZs5x1fLenkohRPSQLLRc= 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=TtjjEYWU; arc=none smtp.client-ip=115.124.30.110 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="TtjjEYWU" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1775719703; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=kJ7vJ+oFAlZFw8EfHMuaHDk+cVLH8+ocGz5ZHIMeP74=; b=TtjjEYWUnRJHP1hL4/OSPMQrPdzL1ELG6UAANkF6FrjgyrigiaE23AAUkiPdbgeFmTi8mO5wpZcoZT49I8OsdDashO3dflCXDsekuzfhZm/cIbvj5i+9Huj4cvnNg5svQsk/DitOgzjeeCGFAIGSzOUaj4RAmDxupKXUWLNrrt8= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R421e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0X0hg9id_1775719701; Received: from 30.221.132.163(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X0hg9id_1775719701 cluster:ay36) by smtp.aliyun-inc.com; Thu, 09 Apr 2026 15:28:22 +0800 Message-ID: <31b4e893-44f4-49b4-935f-9cf37b5a0790@linux.alibaba.com> Date: Thu, 9 Apr 2026 15:28:21 +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 , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, Yuhao Jiang , stable@vger.kernel.org References: From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/4/9 14:57, Junrui Luo wrote: > In z_erofs_lz4_handle_overlap(), the index expression > "rq->outpages - rq->inpages + i" is computed in unsigned arithmetic. > If outpages < inpages, the subtraction wraps to a large value and > the subsequent rq->out[] access reads past the decompressed_pages > array. > > z_erofs_map_sanity_check() does not enforce m_plen <= m_llen, so a > crafted image declaring m_plen > m_llen can produce outpages < inpages. For this kind of stuff, do you have a reproducer? `m_plen > m_llen` can happen on partial decoding only. > > The in-place branch is currently unreachable: it requires both > partial_decoding == false and omargin > 0, but these are mutually > exclusive. partial_decoding == false requires pcl->length == m_llen, > which in turn requires (offset + end == m_la + m_llen) where > offset + end is page-aligned from folio boundaries. This forces I'm not sure what you're saying, but I don't think you really understand the entire logic. > m_la + m_llen to be page-aligned, making oend page-aligned and > omargin zero. `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. Thanks, Gao Xiang