linux-ext4 - ext2 readdir/lookup/check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Nov 2006 09:25:19 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	ext4 development <linux-ext4@...r.kernel.org>
Subject: ext2 readdir/lookup/check_page behavior

the fsfuzzer has been keeping me busy lately ;-)

http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html

has an image with a corrupt directory inode - despite having only 4 blocks, it 
has an extremely large i_size.

readdir & lookup seem to behave differently when ext2_check_page fails for the 
bogus high-index pages.

an "ls" immediately fails with "EIO" because:

ext2_readdir
   ext2_get_page
     ext2_check_page

and if ext2_check_page fails,

                 if (IS_ERR(page)) {
                         ext2_error(sb, __FUNCTION__,
                                    "bad page in #%lu",
                                    inode->i_ino);
                         filp->f_pos += PAGE_CACHE_SIZE - offset;
                         return -EIO;
                 }

however, if you try to "cat *" it spews errors over and over because it gets 
into lookup:

ext2_lookup
   ext2_inode_by_name
     ext2_find_entry
       loop over all pages within i_size calling ext2_get_page

and ext2_find_entry does not break out of the loop when a bad page is found, it 
keeps trying the -next- page, causing a storm of printks as it churns through 
all these bogus pages/offsets.

It seems odd to me that readdir bails out with an error on the first bad page, 
while lookup keeps trying.  Shouldn't these be consistent?  And if so, which is 
the desired behavior?

If we truly wish to keep trying after an error, perhaps adding a "bad page 
count" to the inode_info struct, so that we can stop after a predetermined 
number of errors, might be an option.

Or, perhaps a check high up that says if i_size doesn't correlate to i_blocks, 
this inode is corrupt, and bail out early.

Thoughts?

Thanks,

-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html