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 C166115AE3 for ; Wed, 9 Aug 2023 10:44:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 414E1C433C8; Wed, 9 Aug 2023 10:44:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1691577875; bh=auQ52G1uv/fBXl0ISBN+jSXMtoyKyYwBp1qb5Qn69no=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AXiyVHyuHDSm5rr7T/o6LaTeZiJjZ3Qn81lKsRycdeLftC0I1YH1dIY3wrEI4A5bE yf4a2oCfVnS6llbZSUDqklBmxLMUaFgDRPJ4JWgxEHmQI9YYpJs+ETD3AimCsVo8cf 70OS8ouYdal6LRP9H2Bv/1rh39uthEFr3nyNOO8U= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Shijie Sun , Yue Hu , Chao Yu , Gao Xiang , Sasha Levin Subject: [PATCH 6.4 025/165] erofs: fix wrong primary bvec selection on deduplicated extents Date: Wed, 9 Aug 2023 12:39:16 +0200 Message-ID: <20230809103643.634655293@linuxfoundation.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230809103642.720851262@linuxfoundation.org> References: <20230809103642.720851262@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Gao Xiang [ Upstream commit 94c43de73521d8ed7ebcfc6191d9dace1cbf7caa ] When handling deduplicated compressed data, there can be multiple decompressed extents pointing to the same compressed data in one shot. In such cases, the bvecs which belong to the longest extent will be selected as the primary bvecs for real decompressors to decode and the other duplicated bvecs will be directly copied from the primary bvecs. Previously, only relative offsets of the longest extent were checked to decompress the primary bvecs. On rare occasions, it can be incorrect if there are several extents with the same start relative offset. As a result, some short bvecs could be selected for decompression and then cause data corruption. For example, as Shijie Sun reported off-list, considering the following extents of a file: 117: 903345.. 915250 | 11905 : 385024.. 389120 | 4096 ... 119: 919729.. 930323 | 10594 : 385024.. 389120 | 4096 ... 124: 968881.. 980786 | 11905 : 385024.. 389120 | 4096 The start relative offset is the same: 2225, but extent 119 (919729.. 930323) is shorter than the others. Let's restrict the bvec length in addition to the start offset if bvecs are not full. Reported-by: Shijie Sun Fixes: 5c2a64252c5d ("erofs: introduce partial-referenced pclusters") Tested-by Shijie Sun Reviewed-by: Yue Hu Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20230719065459.60083-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin --- fs/erofs/zdata.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c index 4a1c238600c52..470988bb7867e 100644 --- a/fs/erofs/zdata.c +++ b/fs/erofs/zdata.c @@ -1110,10 +1110,11 @@ static void z_erofs_do_decompressed_bvec(struct z_erofs_decompress_backend *be, struct z_erofs_bvec *bvec) { struct z_erofs_bvec_item *item; + unsigned int pgnr; - if (!((bvec->offset + be->pcl->pageofs_out) & ~PAGE_MASK)) { - unsigned int pgnr; - + if (!((bvec->offset + be->pcl->pageofs_out) & ~PAGE_MASK) && + (bvec->end == PAGE_SIZE || + bvec->offset + bvec->end == be->pcl->length)) { pgnr = (bvec->offset + be->pcl->pageofs_out) >> PAGE_SHIFT; DBG_BUGON(pgnr >= be->nr_pages); if (!be->decompressed_pages[pgnr]) { -- 2.40.1