Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3360536pxf; Mon, 22 Mar 2021 04:50:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4UsURoXR38S3hUBZKrA+DDFGBxm30EeeV5NwGBtp8K8lLVl9wRCYH1fKnd9AWWj5yleo/ X-Received: by 2002:a17:907:37a:: with SMTP id rs26mr18816975ejb.336.1616413805959; Mon, 22 Mar 2021 04:50:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616413805; cv=none; d=google.com; s=arc-20160816; b=OHHFq9Vqzz8/JXw+aT/eWUEk2xxOG6T2Jl//t9+NDDpM2RM6+w1h9cyXZFhk92XZkn 9bmd1DA90wCeljKizV2lQ67xpJd7IUz45TVaRmDyoJJO57u0NHtry1vge7Y91zLwMAaT VK7rxH277haNt4z9UZFPqmHveZdBdMfxyiOADzMqb6Ah3zazrbShe67eDxYE90l0toBp qvAV7FuI1smlG7eY2mG876/664NWxIwpiYWsG2WWA9XerktZxq9NHmHSgOl1d9C4qWmN CiDFSrO9AR0CVhBbISps2pFf01lvsVnqntE27cqcROFz/tNUBa3ouuZzvaOZHk0ky7HP McKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=6pmjyl286V4wde9Q7o/J1gFJbTIYW82XzcQQMLNFO90=; b=ED1lSh3QpTh10uDg6lmwMElPHvwT+Fu/CrrGhTqgUkB+bjMhr7C/FrROXx7vB2ib8D E2VRauVwtDixEGq/cZaehA7F+hJF+52eBWqsE9xhz9TjX6xiTAQKpTsOzrudE21/BErd KxzoVT4J4oKlgn4jYUeQ9eswnCrbFBwNRM0HMgsSXn3xTbzr/f6h1THg+Sf7YPLjvsZ+ SMlIgwGWNQ+nkpNKsGyF/+gBCAD9fSDzpogn56ZKew7spmTnVClhzXeb+bLZTsvNxKo0 KLzL+ZWUihtz+39fka3+tykzzhjX0oB/D9lGO4QCWAIwRWiAovmL/0ECInaEzaAupU6T qjAw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 39si11874301edq.111.2021.03.22.04.49.41; Mon, 22 Mar 2021 04:50:05 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230182AbhCVLs3 (ORCPT + 99 others); Mon, 22 Mar 2021 07:48:29 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:14123 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229728AbhCVLr5 (ORCPT ); Mon, 22 Mar 2021 07:47:57 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4F3t431MfLz19H3b; Mon, 22 Mar 2021 19:45:55 +0800 (CST) Received: from szvp000203569.huawei.com (10.120.216.130) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.498.0; Mon, 22 Mar 2021 19:47:42 +0800 From: Chao Yu To: CC: , , , Chao Yu , butt3rflyh4ck Subject: [PATCH] f2fs: fix to avoid out-of-bounds memory access Date: Mon, 22 Mar 2021 19:47:30 +0800 Message-ID: <20210322114730.71103-1-yuchao0@huawei.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.120.216.130] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org butt3rflyh4ck reported a bug found by syzkaller fuzzer with custom modifications in 5.12.0-rc3+ [1]: dump_stack+0xfa/0x151 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x82/0x32c mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 f2fs_test_bit fs/f2fs/f2fs.h:2572 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] get_next_nat_page fs/f2fs/node.c:123 [inline] __flush_nat_entry_set fs/f2fs/node.c:2888 [inline] f2fs_flush_nat_entries+0x258e/0x2960 fs/f2fs/node.c:2991 f2fs_write_checkpoint+0x1372/0x6a70 fs/f2fs/checkpoint.c:1640 f2fs_issue_checkpoint+0x149/0x410 fs/f2fs/checkpoint.c:1807 f2fs_sync_fs+0x20f/0x420 fs/f2fs/super.c:1454 __sync_filesystem fs/sync.c:39 [inline] sync_filesystem fs/sync.c:67 [inline] sync_filesystem+0x1b5/0x260 fs/sync.c:48 generic_shutdown_super+0x70/0x370 fs/super.c:448 kill_block_super+0x97/0xf0 fs/super.c:1394 The root cause is, if nat entry in checkpoint journal area is corrupted, e.g. nid of journalled nat entry exceeds max nid value, during checkpoint, once it tries to flush nat journal to NAT area, get_next_nat_page() may access out-of-bounds memory on nat_bitmap due to it uses wrong nid value as bitmap offset. [1] https://lore.kernel.org/lkml/CAFcO6XOMWdr8pObek6eN6-fs58KG9doRFadgJj-FnF-1x43s2g@mail.gmail.com/T/#u Reported-by: butt3rflyh4ck Signed-off-by: Chao Yu --- fs/f2fs/node.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index caf43970510e..8311b2367c7c 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -2790,6 +2790,9 @@ static void remove_nats_in_journal(struct f2fs_sb_info *sbi) struct f2fs_nat_entry raw_ne; nid_t nid = le32_to_cpu(nid_in_journal(journal, i)); + if (f2fs_check_nid_range(sbi, nid)) + continue; + raw_ne = nat_in_journal(journal, i); ne = __lookup_nat_cache(nm_i, nid); -- 2.29.2