Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4365265ybv; Tue, 25 Feb 2020 18:43:00 -0800 (PST) X-Google-Smtp-Source: APXvYqyzarcocw9zY2coHjdmqpisHqYBA1kZLNoHqKlIiwgTG8DjZiAcmdBhE+13Yoc4SH4g7thj X-Received: by 2002:aca:f2c5:: with SMTP id q188mr1448032oih.113.1582684980679; Tue, 25 Feb 2020 18:43:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582684980; cv=none; d=google.com; s=arc-20160816; b=TVGxWEXdmSWxHCJJAEdH+KaMB7ELubJM6CesYGe+l0Qt9yvoAQQIIRzmR9u5xnMRWI OBEtKMLCbsDNGsJGa6Yed8+FyaTQKUfSfGmnDTvfG5NCusdDqiwv9pFHj3T4Rr9uaKjj 9mz9m3RIoBRlggCWqXpsL0XDyXY3lVCGap7J1TIGgWMvtE/BxTPDrMmMCJDr6ClnFB07 AUC+A8rsW9jUM9EimIFuw2E2eMqJ1PtkCvvhur5jJUv69me05gx4NDzKIcBrTbuAB8r/ lrSkA4UNoA8PJKjCUL8aZzIFzNCQ9DkXTOAyqRX4ymFfUDNPxiZo6VlxF2Qq8ohJ4Ty/ H3Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ezVDcF0TjkU03rUttoYHcps4McWXwwULhkMpjzE1fEQ=; b=nNJL+B2GZ9rpGxcKCDMwvjSgromNb4WwLIHIaY6lI8ePwR8BqMjurMCvTBvdJtE+D8 SBLRK7NObOCe+zRdmHW3cnTASQ265t50HOuCQAQ4Vy2DfyJr0MqvRfZs8e9VzcP9roBs OzVxQFQR+h9PFBbofoZhn3qI1Q+0TA9hxYBD/mhlPiNNf7e65gsyaDXTnn/YFshnBhAu XTwxaBg0sOJtQA0/AU2aDlbXMkDWfDawlx8NRicl7xAbz1pP17T/wjKVtRVF+6FLDN7O hnTDnjd9Kj9K0Z8SsVvBOtYwAfF9UPEdirh3Xar11Qv7rhPOoy84vpICLjHURA6SCAkI r53Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s16si446472otq.253.2020.02.25.18.42.22; Tue, 25 Feb 2020 18:43:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729623AbgBZCmU (ORCPT + 99 others); Tue, 25 Feb 2020 21:42:20 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:2592 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728989AbgBZCmT (ORCPT ); Tue, 25 Feb 2020 21:42:19 -0500 Received: from DGGEMM402-HUB.china.huawei.com (unknown [172.30.72.57]) by Forcepoint Email with ESMTP id CF60A79D635F234BD9D2; Wed, 26 Feb 2020 10:42:17 +0800 (CST) Received: from dggeme762-chm.china.huawei.com (10.3.19.108) by DGGEMM402-HUB.china.huawei.com (10.3.20.210) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 26 Feb 2020 10:42:17 +0800 Received: from architecture4 (10.160.196.180) by dggeme762-chm.china.huawei.com (10.3.19.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 26 Feb 2020 10:42:16 +0800 Date: Wed, 26 Feb 2020 10:40:49 +0800 From: Gao Xiang To: Eric Biggers CC: Chao Yu , , Miao Xie , LKML , Lasse Collin Subject: Re: [PATCH 3/3] erofs: handle corrupted images whose decompressed size less than it'd be Message-ID: <20200226024047.GA106025@architecture4> References: <20200226023011.103798-1-gaoxiang25@huawei.com> <20200226023011.103798-3-gaoxiang25@huawei.com> <20200226023458.GB1053@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200226023458.GB1053@sol.localdomain> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [10.160.196.180] X-ClientProxiedBy: dggeme704-chm.china.huawei.com (10.1.199.100) To dggeme762-chm.china.huawei.com (10.3.19.108) X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On Tue, Feb 25, 2020 at 06:34:58PM -0800, Eric Biggers wrote: > On Wed, Feb 26, 2020 at 10:30:11AM +0800, Gao Xiang wrote: > > As Lasse pointed out, "Looking at fs/erofs/decompress.c, > > the return value from LZ4_decompress_safe_partial is only > > checked for negative value to catch errors. ... So if > > I understood it correctly, if there is bad data whose > > uncompressed size is much less than it should be, it can > > leave part of the output buffer untouched and expose the > > previous data as the file content. " > > > > Let's fix it now. > > > > Cc: Lasse Collin > > Signed-off-by: Gao Xiang > > Shouldn't fixes like this have a Fixes tag and Cc stable? > > - Eric Thanks for pointing out. *thumb up* I reminded Fixes and Cc tags when I sent out. Yet I'm not quite sure if these have some other potential concernes which could cause unexpected behavior for normal images (It seems impossible but not quite sure.) I'd like to leave these two commits for corrupted images to mainline and our products for a while and manually backport to stable kernels and send them to stable mailing list later. I keep these fixes in mind all the time. Thanks, Gao Xiang