Re: Bad ext3/nfs DoS bug

linux
2006-07-22T03:38:35Z

>> +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.

Er... I'm not an authoritative speaker, but it seems very simple to me.

Inodes are indexed starting from 1; the index 0 is reserved, and the first
inode on disk is number 1.

Thus, potentially valid inode numbers are 1 through s_inodes_count,
inclusive. Thus the <=. If this were a standard 0-based index, it would
be <, but it's not.

Further, a range of low inode numbers are reserved for special purposes.
Only a few inode numbers in this range are valid. However, these
numbers are still assigned space in the inode tables.

The only confusing term is EXT3_FIRST_INO, which is actually
more like EXT3_RESERVED_INODES. The same 1-based indexing explains
the use of > rather than >= there.