Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1371311yba; Tue, 2 Apr 2019 07:41:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqxyhiq+OR7YG0SvzTXa0q5f3WApnlU0GYQyYNeQ0GblGJ93becG4iRqcTJ9ZgCZzYiYRhpX X-Received: by 2002:a63:c706:: with SMTP id n6mr33562584pgg.310.1554216115936; Tue, 02 Apr 2019 07:41:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554216115; cv=none; d=google.com; s=arc-20160816; b=HzyEv9OSOGm1zhMB5G2wI3gGEhr2Up6jzByocup3FMR/9FjTaIT20oQrlSIWS7+y8J fqzXcL2VzfaX1Id8o/NS+Fv8t766hQNGovPw/GWPAK30Sjy6DiVUzLvjmd3ThRTeySE7 +mkA5eMA1UzsWqXDPn8zf806HeHwIXoMkWdqHbpdIxxvfRch6aH7eW1XSh83RTvZKgdr usqOaV0SNT6Gy6bUqvOTUg/I0QinevuXJskzbfA/DqVHzQecEdTCBb9/BfNthgrPipD2 PwY6l4/1IOcaOycVwaej7aIiv0Ajy0SmefG/mhRFuuNiRpgqhhPhHdVubZdx31ct/6x5 CLcA== 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=i4is33iBasq6nF2kYe016Of7dDaPINtg9hhN4+gZ+4g=; b=hXeMNfERy4Plcl+sW+wzYidlxluwzj8fmoymXENxJu4lPbB/NxRsyw/pdmtLuZinEi iU6r8lLiebv3tnjsOBRk0Ywd+DBgUI9iBJR5D1OSgjhhFx9eyTcbmrULSqHWWYjwSfoG X8Go256OTMUJdHCT20KD8bCC4lxNep5K5h7z1fiR7E5ZjSEoghANLPz95JI/pWFG5ADw QoWVRK5hp9yPrW1b2gxjpxrg07POZ/txnt1BD3TiDSPfAkEip57oOqBTTZKFNOv/vH9b xtpE/ct9nkhSC6a+3Eb1A8WgbiVv0RPjnV7Oe8m8KlDMwFNI8FLgdbw8521B3LU3dVNx mE7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l62si2912765pge.579.2019.04.02.07.41.40; Tue, 02 Apr 2019 07:41:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731807AbfDBNmO (ORCPT + 99 others); Tue, 2 Apr 2019 09:42:14 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:43714 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731540AbfDBNkM (ORCPT ); Tue, 2 Apr 2019 09:40:12 -0400 Received: from [167.98.27.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hBJe6-0002no-9v; Tue, 02 Apr 2019 14:40:10 +0100 Received: from ben by deadeye with local (Exim 4.92) (envelope-from ) id 1hBJdx-0004vL-12; Tue, 02 Apr 2019 14:40:01 +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 , "Steve Graham" , "Theodore Ts'o" Date: Tue, 02 Apr 2019 14:38:27 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 61/99] ext4: include terminating u32 in size of xattr entries when expanding inodes In-Reply-To: X-SA-Exim-Connect-IP: 167.98.27.226 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.65-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Theodore Ts'o commit a805622a757b6d7f65def4141d29317d8e37b8a1 upstream. In ext4_expand_extra_isize_ea(), we calculate the total size of the xattr header, plus the xattr entries so we know how much of the beginning part of the xattrs to move when expanding the inode extra size. We need to include the terminating u32 at the end of the xattr entries, or else if there is uninitialized, non-zero bytes after the xattr entries and before the xattr values, the list of xattr entries won't be properly terminated. Reported-by: Steve Graham Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- fs/ext4/xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1340,7 +1340,7 @@ retry: end = (void *)raw_inode + EXT4_SB(inode->i_sb)->s_inode_size; min_offs = end - base; last = entry; - total_ino = sizeof(struct ext4_xattr_ibody_header); + total_ino = sizeof(struct ext4_xattr_ibody_header) + sizeof(u32); error = xattr_check_inode(inode, header, end); if (error)