From patchwork Wed Jun 13 04:52:05 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Theodore Ts'o X-Patchwork-Id: 928667 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-ext4-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=thunk.org header.i=@thunk.org header.b="C0oNlMV8"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 415DrD3ff7z9s4n for ; Wed, 13 Jun 2018 14:52:12 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933366AbeFMEwL (ORCPT ); Wed, 13 Jun 2018 00:52:11 -0400 Received: from imap.thunk.org ([74.207.234.97]:35368 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754430AbeFMEwK (ORCPT ); Wed, 13 Jun 2018 00:52:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LL5lscHIkYz6VdH2GbBzDIdIHKLZORvA3YBW866PAVk=; b=C0oNlMV8fZE1J1BxV2c1iG18YK AXREhVriijmoftfS8GdKqoFozhzFli9rV14GndwRZr5cYnPxvAwZ3GBP3qFGNSKeQ80FmOD/rWcjz 7RyQvnivjuNfUn12v/bV9/a1nVCOpwHcU6ofnCgxhcCIywDzBScQZFSW7B920Z0CxA2I=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fSxlR-0005Pz-VC; Wed, 13 Jun 2018 04:52:10 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id EC1F67A2F11; Wed, 13 Jun 2018 00:52:08 -0400 (EDT) From: Theodore Ts'o To: Ext4 Developers List Cc: wen.xu@gatech.edu, Theodore Ts'o Subject: [PATCH 2/2] ext4: always verify the magic number in xattr blocks Date: Wed, 13 Jun 2018 00:52:05 -0400 Message-Id: <20180613045205.19240-2-tytso@mit.edu> X-Mailer: git-send-email 2.18.0.rc0 In-Reply-To: <20180613045205.19240-1-tytso@mit.edu> References: <20180613045205.19240-1-tytso@mit.edu> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org If there an inode points to a block which is also some other type of metadata block (such as a block allocation bitmap), the buffer_verified flag can be set when it was validated as that other metadata block type; however, it would make a really terrible external attribute block. The reason why we use the verified flag is to avoid constantly reverifying the block. However, it doesn't take much overhead to make sure the magic number of the xattr block is correct, and this will avoid potential crashes. https://bugzilla.kernel.org/show_bug.cgi?id=200001 https://bugzilla.kernel.org/show_bug.cgi?id=199997 Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger --- fs/ext4/xattr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 230ba79715f6..0263692979ec 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -230,12 +230,12 @@ __ext4_xattr_check_block(struct inode *inode, struct buffer_head *bh, { int error = -EFSCORRUPTED; - if (buffer_verified(bh)) - return 0; - if (BHDR(bh)->h_magic != cpu_to_le32(EXT4_XATTR_MAGIC) || BHDR(bh)->h_blocks != cpu_to_le32(1)) goto errout; + if (buffer_verified(bh)) + return 0; + error = -EFSBADCRC; if (!ext4_xattr_block_csum_verify(inode, bh)) goto errout;