Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp727317ybi; Fri, 2 Aug 2019 03:17:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqzEky0FWfhx4WPDwQD4ZQWD87nYusS1amaAVpabZrCdvRf0Zq2DouCyU4tC85CuI7WNi+EM X-Received: by 2002:a63:c70d:: with SMTP id n13mr122318106pgg.171.1564741049489; Fri, 02 Aug 2019 03:17:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564741049; cv=none; d=google.com; s=arc-20160816; b=dsQtX0QUDM83IrYyorDSxoL2bnGLJGNGdDsVWlUJzM5F/2+3OY93rHTZaSM6195bSx uQu3RaLfRJ5OUBEH42XdOO2Vl7dLgVJgxe+We6sabSonLQTDOdjxr03iVDN3LI4BxNqj 2u/aKbRp1OzRCfr2iPK8DQzaHgj2PYgR169RJFko171wAixGR31tA4Mh2e6FKCb0FzY2 XgWdi/VPvk15ACLv8n+DvKCW+RD0hzlrzYU2kMuaVo5qAkA+Qdnkgt9CAokzm3aqJbQx vTb7ZqGzPJJyyqUTgTEZKG8KVXaeVnT8HwzXaQQh3dBO8B/SxL7ok+rX3/bMXV4tD8Ic kSrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=b8jH7eAf3IghUEiBSQKnRzd6QNQiMXWWCa8itWyzRuY=; b=KaPTnbjFQuHeCZkC5KVlQOW28W8WjN6Qd+VZw+uw/VVMaBbc+v5pNXh8zIIeXBVExK 6zUfMfdNtXgjMIVwhKE7BhyFAQLjPonbtWr62OhPoww1jKABlI3GYpwwKgNPH+9/90xa 5x8eNBVkqmozsTlg3+MeRLtSu9fN5gjIJiofyWV0Vtuem7yJXsEZGL4oqDX+TO+sTN0B Te+bRA8eC1fQgIUDqJOzohmwakimyXD8HG4XuZgJwzUlh2eM1hZzS5q8Lb9eKC99r5nb D3guzqBQGilgI9A2kg0mB2CPA5gPNDbqym2BXu4ZAPMYSqh4t7jFYSstUTB1dvDJ+qcK lFMg== 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 i18si25911235pfa.23.2019.08.02.03.17.13; Fri, 02 Aug 2019 03:17:29 -0700 (PDT) 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 S2389232AbfHBKQS (ORCPT + 99 others); Fri, 2 Aug 2019 06:16:18 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:47978 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732472AbfHBKQR (ORCPT ); Fri, 2 Aug 2019 06:16:17 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id F15548CA8EEC0A7AC45B; Fri, 2 Aug 2019 18:16:15 +0800 (CST) Received: from szvp000203569.huawei.com (10.120.216.130) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.439.0; Fri, 2 Aug 2019 18:16:05 +0800 From: Chao Yu To: CC: , , , Chao Yu Subject: [PATCH] Revert "f2fs: avoid out-of-range memory access" Date: Fri, 2 Aug 2019 18:15:48 +0800 Message-ID: <20190802101548.96543-1-yuchao0@huawei.com> X-Mailer: git-send-email 2.18.0.rc1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.120.216.130] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As Pavel Machek reported: "We normally use -EUCLEAN to signal filesystem corruption. Plus, it is good idea to report it to the syslog and mark filesystem as "needing fsck" if filesystem can do that." Still we need improve the original patch with: - use unlikely keyword - add message print - return EUCLEAN However, after rethink this patch, I don't think we should add such condition check here as below reasons: - We have already checked the field in f2fs_sanity_check_ckpt(), - If there is fs corrupt or security vulnerability, there is nothing to guarantee the field is integrated after the check, unless we do the check before each of its use, however no filesystem does that. - We only have similar check for bitmap, which was added due to there is bitmap corruption happened on f2fs' runtime in product. - There are so many key fields in SB/CP/NAT did have such check after f2fs_sanity_check_{sb,cp,..}. So I propose to revert this unneeded check. This reverts commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a. Signed-off-by: Chao Yu --- fs/f2fs/segment.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 9693fa4c8971..2eff9c008ae0 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -3492,11 +3492,6 @@ static int read_compacted_summaries(struct f2fs_sb_info *sbi) seg_i = CURSEG_I(sbi, i); segno = le32_to_cpu(ckpt->cur_data_segno[i]); blk_off = le16_to_cpu(ckpt->cur_data_blkoff[i]); - if (blk_off > ENTRIES_IN_SUM) { - f2fs_bug_on(sbi, 1); - f2fs_put_page(page, 1); - return -EFAULT; - } seg_i->next_segno = segno; reset_curseg(sbi, i, 0); seg_i->alloc_type = ckpt->alloc_type[i]; -- 2.18.0.rc1