public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Andrew Morton <akpm@osdl.org>
Cc: Neil Brown <neilb@suse.de>,
	jack@suse.cz, 20@madingley.org, marcel@holtmann.org,
	linux-kernel@vger.kernel.org, sct@redhat.com,
	Andreas Dilger <adilger@clusterfs.com>
Subject: Re: Bad ext3/nfs DoS bug
Date: Sat, 22 Jul 2006 09:17:59 -0400	[thread overview]
Message-ID: <20060722131759.GC7321@thunk.org> (raw)
In-Reply-To: <20060721170627.4cbea27d.akpm@osdl.org>

Sorry, OLS and some work-related emergencies have been hitting hard
this week, so I've been deferred doing a full review of Jan's patch.
Hopefully after OLS I'll be able to comment more fully.

On Fri, Jul 21, 2006 at 05:06:27PM -0700, Andrew Morton wrote:
> There are strange things happening in here.
> 
> > +static inline int ext3_valid_inum(struct super_block *sb, unsigned long ino)
> > +{
> > +	return ino == EXT3_ROOT_INO ||
> > +		ino == EXT3_JOURNAL_INO ||
> > +		ino == EXT3_RESIZE_INO ||
> > +		(ino > EXT3_FIRST_INO(sb) &&
> > +		 ino <= le32_to_cpu(EXT3_SB(sb)->s_es->s_inodes_count));
> > +}
> 
> One would expect the inode validity test to be
> 
> 	(ino >= EXT3_FIRST_INO(sb)) && (ino < ...->s_inodes_count))
>
> but even this assumes that s_inodes_count is misnamed and really should be
> called s_last_inode_plus_one.  If it is not misnamed then the validity test
> should be
> 
> 	(ino >= EXT3_FIRST_INO(sb)) &&
> 		(ino < EXT3_FIRST_INO(sb) + ...->s_inodes_count))
> 
> Look through the filesystem for other uses of EXT3_FIRST_INO().  It's all
> rather fishily inconsistent.

I don't think there's anything in consistent.  Basically, inodes are 1
based (inode number 0 in a directory entry means that the file is
deleted and the directory entry is freed).  Hence valid inode numbers
are between 1 and s_inodes_count, inclusive.

Inodes between 1 and EXT3_FIRST_INO-1 (inclusive) are reserved, are
should always be marked as in use in the inode allocation bitmap.
EXT3_FIRST_INO (which is 11 on all ext3 filesystems to date) is
generally the lost+found directory, but that's just because it is the
first file/directory which is allocated by mke2fs.  So EXT3_FIRST_INO
representes the first inode which can be allocated by userspace.  (The
root inode doesn't fall in this category because it can never be
deleted or reallocated after the filesystem is created, and as a nod
to Unix filesystem history, it has inode #2).

The net of all of this is the inode validity test should be:

 	(ino >= EXT3_FIRST_INO(sb)) && (ino <= ...->s_inodes_count))

However, I would suggest that we *not* allow remote NFS users to get
access to the journal inode or the resize inode, please?  That's only
going to cause mischief of the DoS attack kind.....  

						- Ted


  reply	other threads:[~2006-07-22 13:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-17 13:01 Bad ext3/nfs DoS bug James
2006-07-17 13:06 ` Marcel Holtmann
2006-07-17 18:43 ` Marcel Holtmann
2006-07-18  7:55 ` Marcel Holtmann
2006-07-18 14:56   ` James
2006-07-18 15:22     ` Marcel Holtmann
2006-07-18 15:23       ` James
2006-07-18 20:18         ` Marcel Holtmann
2006-07-19  9:28           ` James
2006-07-19 15:55             ` Jan Kara
2006-07-20  4:46               ` Neil Brown
2006-07-20 16:06                 ` Jan Kara
2006-07-20 20:11                   ` James
2006-07-21  6:44                     ` Neil Brown
2006-07-21  6:39                   ` Neil Brown
2006-07-21 14:24                     ` Jan Kara
2006-07-22  0:06                     ` Andrew Morton
2006-07-22 13:17                       ` Theodore Tso [this message]
2006-07-25  1:56                         ` Andrew Morton
2006-07-25  2:21                           ` Neil Brown
2006-07-26 17:12                             ` Eric Sandeen
2006-07-26 23:53                               ` Neil Brown
2006-07-27 18:32                                 ` Eric Sandeen
2006-07-27 19:12                                   ` Christoph Hellwig
2006-07-28  0:34                                     ` Neil Brown
2006-07-28 13:27                                     ` Peter Staubach
2006-07-28 13:30                                       ` Christoph Hellwig
2006-07-25  2:36                           ` Neil Brown
2006-07-25 18:27                             ` Eric Sandeen
2006-07-21  0:42                 ` Marcel Holtmann
2006-07-21 12:29                   ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2006-07-22  3:38 linux

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=20060722131759.GC7321@thunk.org \
    --to=tytso@mit.edu \
    --cc=20@madingley.org \
    --cc=adilger@clusterfs.com \
    --cc=akpm@osdl.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=neilb@suse.de \
    --cc=sct@redhat.com \
    /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