linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Chengguang Xu <cgxu519@zoho.com.cn>
Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: remove some redundant corruption checks
Date: Fri, 24 May 2019 00:27:39 -0400	[thread overview]
Message-ID: <20190524042739.GE2532@mit.edu> (raw)
In-Reply-To: <20190523124843.566-1-cgxu519@zoho.com.cn>

On Thu, May 23, 2019 at 08:48:43PM +0800, Chengguang Xu wrote:
> Remove some redundant corruption checks in
> ext4_xattr_block_get() and ext4_xattr_ibody_get()
> because ext4_xattr_check_entries() has done those
> checks.
> 
> Signed-off-by: Chengguang Xu <cgxu519@zoho.com.cn>

I deliberately left in the redundant checks.

That's because we still have issues where a buffer can be verified for
some other block type (say, an allocation bitmap), but if that block
is also referenced as an xattr block, we could cause a kernel crash,
or worse, we might be end up corrupting kernel memory in some way that
would lead to a privilege escalation test.

I would actually prefer that we have enough tests ant the Time Of Use
that we wouldn't need to check the whole xattr block the first time we
read it into memory.  The way we are doing it today, we are very much
vulnerable to TOC/TOU bugs/vulnerabilities.

In the long run we should making the xattr code so careful and robust
that we wouldn't need to use the ext4_xattr_check_entries() except as
a backup safety.  (Today, we depend on it far too much, and there have
been multiple example of deliberately/malicious crafted file systems
which can bypass the checks in ext4_xattr_check_entries() check.  Just
scan fs/ext4/xattr.c for various CVE fixes....)  So if anything we
should be adding more checks to ext4_xattr_block_get(), et. al.

					- Ted

      reply	other threads:[~2019-05-24  4:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 12:48 [PATCH] ext4: remove some redundant corruption checks Chengguang Xu
2019-05-24  4:27 ` Theodore Ts'o [this message]

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=20190524042739.GE2532@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=cgxu519@zoho.com.cn \
    --cc=linux-ext4@vger.kernel.org \
    /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).