linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>, "Xu, Wen" <wen.xu@gatech.edu>
Subject: Re: [PATCH] xfs: verify size-vs-format for symlinks & dirs
Date: Mon, 27 Aug 2018 14:41:40 +1000	[thread overview]
Message-ID: <20180827044140.GG2234@dastard> (raw)
In-Reply-To: <02c044f4-a1d9-b911-2b41-74d6d49f9242@redhat.com>

On Sun, Aug 26, 2018 at 09:19:19PM -0500, Eric Sandeen wrote:
> On 8/26/18 8:43 PM, Dave Chinner wrote:
> > Now, size checks - if a directory inode data fork is in extent or
> > btree format, then it must be at least in block form and so it's
> > size must be equal to or larger than the directory block size.
> > Hence the above check misses a whole range on invalid directory
> > sizes for extent/btree forms. I think we should check directories
> > against against the directory block size, so avoid needing to trust
> > any other inode fields at all.
> > 
> > Symlinks, though, aren't so nice. Even a short symlink can be pushed
> > into extent form if enough attributes are created, and the size
> > remains the same even though it now consumes entire blocks, so I
> > think we can only check against XFS_IFORK_DSIZE - there's nothing
> > else we can verify against.
> > 
> > so maybe something like this? 
> 
> I like this structure better, yes.
> 
> > 	if (ip->i_d.di_format != XFS_DINODE_FMT_LOCAL) {
> > 		/*
> > 		 * types that can be in local form need size checks
> > 		 * to ensure they have the right amount of data in
> > 		 * them to be in non-local form
> > 		 */
> > 		switch (mode & S_IFMT) {
> > 		case S_IFDIR:
> > 			if (ip->i_d.di_size < mp->m_dir_geo->blksize)
> > 				return __this_address;
> > 			break;
> 
> TBH, I wasn't working from first principles, just looking at
> process_check_inode_sizes():
> 
>         xfs_fsize_t     size = be64_to_cpu(dino->di_size);
> 
>         switch (type)  {
> 
>         case XR_INO_DIR:
>                 if (size <= XFS_DFORK_DSIZE(dino, mp) &&
>                                 dino->di_format != XFS_DINODE_FMT_LOCAL) {
>                         do_warn(
> _("mismatch between format (%d) and size (%" PRId64 ") in directory ino %" PRIu64 "\n"),
>                                 dino->di_format, size, lino);
>                         return 1;
>                 }
> 
> and it's checking dir size against XFS_DFORK_DSIZE not blocksize in repair...?

Sure, but you made me think about it without looking at the repair
code. Yes, the repair code may catch the specific corruption, but
we know that the reapir doesn't always catch everything as well as
it could...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2018-08-27  8:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 20:31 [PATCH] xfs: verify size-vs-format for symlinks & dirs Eric Sandeen
2018-08-27  1:43 ` Dave Chinner
2018-08-27  2:19   ` Eric Sandeen
2018-08-27  4:41     ` Dave Chinner [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=20180827044140.GG2234@dastard \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --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).