From patchwork Tue Feb 8 20:19:18 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Salisbury X-Patchwork-Id: 1590083 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=PMAkz+1D; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4JtZBD0PB2z9s8q for ; Wed, 9 Feb 2022 07:20:04 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1nHWxv-0005ip-RD; Tue, 08 Feb 2022 20:19:55 +0000 Received: from smtp-relay-canonical-0.internal ([10.131.114.83] helo=smtp-relay-canonical-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1nHWxv-0005ie-4D for kernel-team@lists.ubuntu.com; Tue, 08 Feb 2022 20:19:55 +0000 Received: from jupiter.buildd (1.general.jsalisbury.us.vpn [10.172.66.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id 97A1A3F1C0 for ; Tue, 8 Feb 2022 20:19:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1644351594; bh=lVmcnuPyDNpQuPFAzodTgYMCKhI0MFTQt8k5HbRxRg0=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=PMAkz+1DSaiH1ToKK0tBmkK28Y08cLPBFQsUihTCbOds0PnCGckvqhX1xRQ2bZu3d sgpBTaq19zj6dpl8m0HRAItk94bVfs/h2s9QSNB7Y5HJGHDaJ0Gg1LS0WbBURcAr6G j6aWxzsRqok6V5MyRxvsr7BWm7XbyKhM4Dz4VcbspkfQl+7rmT1mtgSwgzeon7PWnk vbKuAnealeAn/vgGHUFI17Eh9OCil8NrNPleCRmpJH2KgWkVWYA/v8U5KZL5+4N+eJ axJMeGgU8CWnJcUqa+99LFFMYoYcwG1gpBZI5Pghz+Ma3brtHzO2s6SsJAoateIGqY 0w6hKTh+2T40g== From: Joseph Salisbury To: kernel-team@lists.ubuntu.com Subject: [SRU][Bionic][PATCH 1/1] f2fs: fix to avoid out-of-bounds memory access Date: Tue, 8 Feb 2022 15:19:18 -0500 Message-Id: <20220208201918.627085-2-joseph.salisbury@canonical.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20220208201918.627085-1-joseph.salisbury@canonical.com> References: <20220208201918.627085-1-joseph.salisbury@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Chao Yu 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-and-tested-by: butt3rflyh4ck Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim (backported from commit b862676e371715456c9dade7990c8004996d0d9e) [jsalisbury: Preserved name of function check_nid_range() due to later commit 4d57b86dd86404fd8bb4f87d277d5a86a7fe537e, which changes name to f2fs_check_nid_range] CVE-2021-3506 Signed-off-by: Joseph Salisbury Acked-by: Luke Nowakowski-Krijger Acked-by: Stefan Bader --- fs/f2fs/node.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 70428dd6f797..1b1f061ea6e1 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -2406,6 +2406,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 (check_nid_range(sbi, nid)) + continue; + raw_ne = nat_in_journal(journal, i); ne = __lookup_nat_cache(nm_i, nid);