All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@dilger.ca>
To: Eric Biggers <ebiggers@google.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>
Subject: Re: [PATCH 1/3] ext4: forbid i_extra_isize not divisible by 4
Date: Mon, 28 Nov 2016 12:30:35 -0700	[thread overview]
Message-ID: <BC43C27B-D43E-434D-B5C7-121D8388D633@dilger.ca> (raw)
In-Reply-To: <1480228786-106775-1-git-send-email-ebiggers@google.com>

[-- Attachment #1: Type: text/plain, Size: 2672 bytes --]

On Nov 26, 2016, at 11:39 PM, Eric Biggers <ebiggers@google.com> wrote:
> 
> i_extra_isize not divisible by 4 is problematic for several reasons:
> 
> - It causes the in-inode xattr space to be misaligned, but the xattr
>  header and entries are not declared __packed to express this
>  possibility.  This may cause poor performance or incorrect code
>  generation on some platforms.
> - When validating the xattr entries we can read past the end of the
>  inode if the size available for xattrs is not a multiple of 4.
> - It allows the nonsensical i_extra_isize=1, which doesn't even leave
>  enough room for i_extra_isize itself.
> 
> Therefore, update ext4_iget() to consider i_extra_isize not divisible by
> 4 to be an error, like the case where i_extra_isize is too large.
> 
> This also matches the rule recently added to e2fsck for determining
> whether an inode has valid i_extra_isize.
> 
> This patch shouldn't have any noticeable effect on
> non-corrupted/non-malicious filesystems, since the size of ext4_inode
> has always been a multiple of 4.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>

Makes sense.

Reviewed-by: Andreas Dilger <adilger@dilger.ca>

> ---
> fs/ext4/inode.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 861f848..bc99ebe 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4564,10 +4564,12 @@ struct inode *ext4_iget(struct super_block *sb, unsigned long ino)
> 	if (EXT4_INODE_SIZE(inode->i_sb) > EXT4_GOOD_OLD_INODE_SIZE) {
> 		ei->i_extra_isize = le16_to_cpu(raw_inode->i_extra_isize);
> 		if (EXT4_GOOD_OLD_INODE_SIZE + ei->i_extra_isize >
> -		    EXT4_INODE_SIZE(inode->i_sb)) {
> -			EXT4_ERROR_INODE(inode, "bad extra_isize (%u != %u)",
> -				EXT4_GOOD_OLD_INODE_SIZE + ei->i_extra_isize,
> -				EXT4_INODE_SIZE(inode->i_sb));
> +			EXT4_INODE_SIZE(inode->i_sb) ||
> +		    (ei->i_extra_isize & 3)) {
> +			EXT4_ERROR_INODE(inode,
> +					 "bad extra_isize %u (inode size %u)",
> +					 ei->i_extra_isize,
> +					 EXT4_INODE_SIZE(inode->i_sb));
> 			ret = -EFSCORRUPTED;
> 			goto bad_inode;
> 		}
> @@ -4685,6 +4687,7 @@ struct inode *ext4_iget(struct super_block *sb, unsigned long ino)
> 	if (EXT4_INODE_SIZE(inode->i_sb) > EXT4_GOOD_OLD_INODE_SIZE) {
> 		if (ei->i_extra_isize == 0) {
> 			/* The extra space is currently unused. Use it. */
> +			BUILD_BUG_ON(sizeof(struct ext4_inode) & 3);
> 			ei->i_extra_isize = sizeof(struct ext4_inode) -
> 					    EXT4_GOOD_OLD_INODE_SIZE;
> 		} else {
> --
> 2.8.0.rc3.226.g39d4020
> 


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2016-11-28 19:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-27  6:39 [PATCH 1/3] ext4: forbid i_extra_isize not divisible by 4 Eric Biggers
2016-11-27  6:39 ` [PATCH 2/3] ext4: don't read out of bounds when checking for in-inode xattrs Eric Biggers
2016-11-28 19:43   ` Andreas Dilger
2016-12-01 19:52   ` Theodore Ts'o
2016-11-27  6:39 ` [PATCH 3/3] ext4: correctly detect when an xattr value has an invalid size Eric Biggers
2016-11-28 19:50   ` Andreas Dilger
2016-11-28 23:50     ` Eric Biggers
2016-12-01 20:00   ` Theodore Ts'o
2016-11-28 19:30 ` Andreas Dilger [this message]
2016-12-01 19:49 ` [PATCH 1/3] ext4: forbid i_extra_isize not divisible by 4 Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BC43C27B-D43E-434D-B5C7-121D8388D633@dilger.ca \
    --to=adilger@dilger.ca \
    --cc=adilger.kernel@dilger.ca \
    --cc=ebiggers@google.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.