From: Eric Biggers <ebiggers3@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
adilger@dilger.ca, wen.xu@gatech.edu, ebiggers@google.com,
stable@vger.kernel.org
Subject: Re: [PATCH -v2] ext4: limit xattr size to INT_MAX
Date: Fri, 30 Mar 2018 12:50:16 -0700 [thread overview]
Message-ID: <20180330195016.GC180083@gmail.com> (raw)
In-Reply-To: <20180330191320.7270-1-tytso@mit.edu>
Hi Ted,
On Fri, Mar 30, 2018 at 03:13:20PM -0400, Theodore Ts'o wrote:
>
> Also if the xattr block is corrupted, mark the file system as
> containing an error.
Weren't we doing that already?
>
> This issue has been assigned CVE-2018-1095.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=199185
> https://bugzilla.redhat.com/show_bug.cgi?id=1560793
>
> Reported-by: Wen Xu <wen.xu@gatech.edu>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> Cc: stable@vger.kernel.org
I'm still confused why you removed my Fixes: line and the mentions of the bug
affecting external inode xattrs only. Wasn't the size validation correct before
then? We might want to send d7614cc16146 to the stable trees, but after that
the sizes were being validated correctly, right?
> ---
> fs/ext4/xattr.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
> index 63656dbafdc4..d2a9b078e121 100644
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -195,10 +195,14 @@ ext4_xattr_check_entries(struct ext4_xattr_entry *entry, void *end,
>
> /* Check the values */
> while (!IS_LAST_ENTRY(entry)) {
> + u32 size = le32_to_cpu(entry->e_value_size);
> +
> + if (size > INT_MAX)
> + return -EFSCORRUPTED;
> +
> if (entry->e_value_size != 0 &&
> entry->e_value_inum == 0) {
Use 'size' instead of 'entry->e_value_size' here, like in my original patch?
> u16 offs = le16_to_cpu(entry->e_value_offs);
> - u32 size = le32_to_cpu(entry->e_value_size);
> void *value;
>
> /*
> @@ -523,8 +527,10 @@ ext4_xattr_block_get(struct inode *inode, int name_index, const char *name,
> if (error)
> goto cleanup;
> size = le32_to_cpu(entry->e_value_size);
> + error = -ERANGE;
> + if (unlikely(size > INT_MAX))
> + goto cleanup;
> if (buffer) {
> - error = -ERANGE;
> if (size > buffer_size)
> goto cleanup;
> if (entry->e_value_inum) {
> @@ -572,8 +578,10 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
> if (error)
> goto cleanup;
> size = le32_to_cpu(entry->e_value_size);
> + error = -ERANGE;
> + if (unlikely(size > INT_MAX))
> + goto cleanup;
I still think the new checks here are misleading and shouldn't be added. If
someone can actually modify the buffer_head concurrently then they could just
make the size larger than the block but <= INT_MAX, so that the following
page(s) are also copied to the xattr, disclosing memory or crashing. Or they
could modify ->e_value_offs to point past the block. Also since this is not
using a volatile memory access, the compiler is free to reload the value and
assume it's the same.
- Eric
next prev parent reply other threads:[~2018-03-30 19:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180329194125.GC3790@thunk.org>
2018-03-29 21:46 ` [PATCH] ext4: limit xattr size to INT_MAX Theodore Ts'o
2018-03-29 21:54 ` Andreas Dilger
2018-03-30 19:13 ` [PATCH -v2] " Theodore Ts'o
2018-03-30 19:50 ` Eric Biggers [this message]
2018-03-30 21:19 ` Theodore Y. 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=20180330195016.GC180083@gmail.com \
--to=ebiggers3@gmail.com \
--cc=adilger@dilger.ca \
--cc=ebiggers@google.com \
--cc=linux-ext4@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=wen.xu@gatech.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).