Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2238559ybt; Tue, 16 Jun 2020 00:12:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwykpXT/StspLJIf+W+IDEw/ZW9cxxtJqW93YdeVXhSza+/uYU3Ns79W9VivDSKg/KDAosx X-Received: by 2002:a17:906:3952:: with SMTP id g18mr1570295eje.68.1592291571928; Tue, 16 Jun 2020 00:12:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592291571; cv=none; d=google.com; s=arc-20160816; b=aV2akSUJF7pZaP3G5eQLvBQCfNe/Zvo0GAYWhP2pEz3v6VgqNYx7wpMb+QdWCeto6K YHnvLRGkwXx5tv9zNN/YhJKJiTqsKFKcrzZa4ZhOOHtAQAbDFNneNihyrZIOxz5T8uoT XLezjGZ/wsqFl5WKEY5BF6lcBSMvTwFpSUlb6uCIWUQ6WP9ypjCqia9ibwsj5veDnbIH w5T3YGbI7m8x0RjZl/QRyLo+S5VOzgZ2ntQS2mf3vhRp19gKc7SXdrSy281ALUT6OVmX n99tdv4JYxkWQul6hnB+0c+zMeOcwLf0lAZAb+ZdqOIWOGdr1uE48GLHMQL0cLbavR8Y Nfrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=vllV4YW7ARB0RCu1V8imrorIV5uf8RekphNh4hOUgis=; b=UL7Ef+Y0ZaNPLk9GoewllnjirtrqE5JIUyYt/z9Rrb2fl6kM1qKrjiUUA1BxGxGBP/ bwfp3B1RfG+GesIx4j8+/4sZSBQ8J51STsE04rYnbOJpOJL9guRQpId8fzwmw8JeV+/V JO20TBRvYUDHgjm0nF1KYK9fS/9qKDMUb9Ed34HNeKQuwYjR+YtNHNGIYrGhmmo7UwNR hsFxWFLp9ldxA8otIKU7BiHl0eAeCVI4/xnNpdhY9UHkDGkufn5QREGplMHBz2dzia8Y 46p+QjX3TU/b4tonn8VYD6HJVcV/RAsrWopGwZoqQiKmDnm+RNbJqTZItJC+ekjeW4/R q+/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e2si9719934edy.212.2020.06.16.00.12.29; Tue, 16 Jun 2020 00:12:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727047AbgFPHKo (ORCPT + 99 others); Tue, 16 Jun 2020 03:10:44 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:6331 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726091AbgFPHKo (ORCPT ); Tue, 16 Jun 2020 03:10:44 -0400 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id AC51B34C361747865690; Tue, 16 Jun 2020 15:10:38 +0800 (CST) Received: from huawei.com (10.175.127.227) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.487.0; Tue, 16 Jun 2020 15:10:31 +0800 From: Zhihao Cheng To: , CC: , , Subject: [PATCH RFC 0/5] ubifs: Prevent memory oob accessing while dumping node Date: Tue, 16 Jun 2020 15:11:41 +0800 Message-ID: <20200616071146.2607061-1-chengzhihao1@huawei.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We use function ubifs_dump_node() to dump bad node caused by some reasons (Such as bit flipping caused by hardware error, writing bypass ubifs or unknown bugs in ubifs). The node content can not be trusted anymore, so we should prevent memory out-of-bounds accessing while dumping node in following situations: 1. bad node_len: Dumping data according to 'ch->len' which may exceed the size of memory allocated for node. 2. bad node content: Some kinds of node can record additional data, eg. index node and orphan node, make sure the size of additional data not beyond the node length. 3. node_type changes: Read data according to type A, but expected type B, before that, node is allocated according to type B's size. Length of type A node is greater than type B node. Commit acc5af3efa303d5f3 ("ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len") handles situation 1 for data node only, it would be better if we can solve problems in above situations for all kinds of nodes. Patch 1 adds a new parameter 'node_len'(size of memory which is allocated for the node) in function ubifs_dump_node(), safe dumping length of the node should be: minimum(ch->len, c->ranges[node_type].max_len, node_len). Besides, c->ranges[node_type].min_len can not greater than safe dumping length, which may caused by node_type changes(situation 3). Patch 2 reverts commit acc5af3efa303d5f ("ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len") to prepare for patch 3. Patch 3 replaces modified function ubifs_dump_node() in all node dumping places except for ubifs_dump_sleb(). Patch 4 removes unused function ubifs_dump_sleb(), Patch 5 allows ubifs_dump_node() to dump all branches of the index node. Some tests after patchset applied: https://bugzilla.kernel.org/show_bug.cgi?id=208203 Zhihao Cheng (5): ubifs: Limit dumping length by size of memory which is allocated for the node Revert "ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len" ubifs: Pass node length in all node dumping callers ubifs: ubifs_dump_sleb: Remove unused function ubifs: ubifs_dump_node: Dump all branches of the index node fs/ubifs/commit.c | 4 +- fs/ubifs/debug.c | 111 ++++++++++++++++++++++++++------------------ fs/ubifs/debug.h | 5 +- fs/ubifs/file.c | 2 +- fs/ubifs/io.c | 37 +++++---------- fs/ubifs/journal.c | 3 +- fs/ubifs/master.c | 4 +- fs/ubifs/orphan.c | 6 ++- fs/ubifs/recovery.c | 6 +-- fs/ubifs/replay.c | 4 +- fs/ubifs/sb.c | 2 +- fs/ubifs/scan.c | 4 +- fs/ubifs/super.c | 2 +- fs/ubifs/tnc.c | 8 ++-- fs/ubifs/tnc_misc.c | 4 +- fs/ubifs/ubifs.h | 4 +- 16 files changed, 108 insertions(+), 98 deletions(-) -- 2.25.4