Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2344944ybz; Thu, 23 Apr 2020 16:25:51 -0700 (PDT) X-Google-Smtp-Source: APiQypJ+n0PQG1PuMewi9BRH1xP0vir1ZVISrw/qEfp46Ze51Z++auOBZ17ZgZ+K6UW9b5Z7zzEq X-Received: by 2002:a17:907:41b6:: with SMTP id na6mr4641644ejb.119.1587684351262; Thu, 23 Apr 2020 16:25:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587684351; cv=none; d=google.com; s=arc-20160816; b=r06arrjpRMXfshGBX4uFYc30Dmfpao5sbFNjuVm6U+hSaCPtfz/pPE4Xigfk9rBr1j J+q7C2IeFx+aE5YMcrFEdWRJ0FmVd55t4BSPzCrfUPD1IL5t6XfFJ6RcYMoGOq2dyHhH +c8jfPkVlZO9CAhoa/WFD8e7o/sFsyQFiPJvabLkLz1p+tTY/24EC6Sal+mLsRlg6Guc MV8RR/VmYSIw4yFFFsw3dL4wkItfehJdCFC83ljiJq65/DdKTaqWv3kTmDJ8USf0zIVj bOA2O1MzJTXU6p81QokdzBYLw2mAHGTW06ce2F2Un+geBI2o4wMvYVPfPcKeoYQEtDn3 doIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=6nL/rVKGBGSXMCg5puG9vHUL8b/3qrnN9uUo55h+lKs=; b=PI0o/iCqq+GK+a8NIXE7jyaCFg0TuFX1M0ypFSrHj/gtXD+GlyYUSXUwttXAKn34Vd wu6a0R/eR08DqRghGiBBz3j/gIcfwzCmN0XpS+Ir4Y5qcva0lbQzHVoCtOlVSUE+LVpC yBKi4trvm9Si48hMOcy5mopvSWdv3Vkf4TShF4glMoyG+pMdRs+WtVp1RaLSI2yECckG KK/DRGI5Uu9FApRxq8hDVNvQgIKib0BGzoWd5RjCfdbxwN1F+puy/6w1nCTrsWymJiCu w0WOdD9kZkUkArYVdZp9/wWTrg+yQw8xbpbf7NWOGp/V7Uc0zcyqv2BKpyJC4yDB/as6 k0JA== 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 ks15si2140275ejb.223.2020.04.23.16.25.27; Thu, 23 Apr 2020 16:25: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 S1729622AbgDWXYH (ORCPT + 99 others); Thu, 23 Apr 2020 19:24:07 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:48320 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728151AbgDWXGa (ORCPT ); Thu, 23 Apr 2020 19:06:30 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvJ-0004aP-J4; Fri, 24 Apr 2020 00:06:25 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvI-00E6gg-Kk; Fri, 24 Apr 2020 00:06:24 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Ben Hutchings" , "Liu Bo" , "David Sterba" , "Greg Kroah-Hartman" Date: Fri, 24 Apr 2020 00:04:19 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 032/245] Btrfs: memset to avoid stale content in btree node block In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Liu Bo commit 3eb548ee3a8042d95ad81be254e67a5222c24e03 upstream. During updating btree, we could push items between sibling nodes/leaves, for leaves data sections starts reversely from the end of the block while for nodes we only have key pairs which are stored one by one from the start of the block. So we could do try to push key pairs from one node to the next node right in the tree, and after that, we update the node's nritems to reflect the correct end while leaving the stale content in the node. One may intentionally corrupt the fs image and access the stale content by bumping the nritems and causes various crashes. This takes the in-memory @nritems as the correct one and gets to memset the unused part of a btree node. Signed-off-by: Liu Bo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings --- fs/btrfs/extent_io.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -3628,6 +3628,17 @@ static noinline_for_stack int write_one_ if (btrfs_header_owner(eb) == BTRFS_TREE_LOG_OBJECTID) bio_flags = EXTENT_BIO_TREE_LOG; + /* set btree node beyond nritems with 0 to avoid stale content */ + if (btrfs_header_level(eb) > 0) { + u32 nritems; + unsigned long end; + + nritems = btrfs_header_nritems(eb); + end = btrfs_node_key_ptr_offset(nritems); + + memset_extent_buffer(eb, 0, end, eb->len - end); + } + for (i = 0; i < num_pages; i++) { struct page *p = eb->pages[i];