From MOKB-12-11-2006: http://projects.info-pull.com/mokb/MOKB-12-11-2006.html The ext2 filesystem code fails to properly handle corrupted data structures, leading to an exploitable denial of service issue when read operation is being done on a crafted fs stream.
committed in stream U5 build 42.40. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/
I can verify that the fix here has at least improved things. With the fix, I get the same error. The ls process is killable after numerous attempts to kill it with sig 11 on the 42.0.7 kernel. I tried killing it for about 10 minutes when running the -42 kernel and never could kill it.
Mike, the original problem cranked out these messages almost ad infinitum: EXT2-fs error (device loop1): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=24576, inode=0, rec_len=0, name_len=0 EXT2-fs error (device loop1): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=28672, inode=0, rec_len=0, name_len=0 EXT2-fs error (device loop1): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=32768, inode=0, rec_len=0, name_len=0 EXT2-fs error (device loop1): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=36864, inode=0, rec_len=0, name_len=0 EXT2-fs error (device loop1): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=40960, inode=0, rec_len=0, name_len=0 With the fix, it should exit with an error with probably only one of these messages, at most. Can you describe exactly how you tested this fix, you still say "the same error" - which error is that? Thanks, -Eric
Eric, I was seeing the same "ext2_check_page: bad entry in directory #2:" messages pretty much continuously with 42.0.7, the one difference was I could kill the ls process (with some difficulty) . Once the ls process died, the messages stopped. With -42 I couldn't do anything to get the ls process to die. I'll go ahead and run this one a bit more on a couple of other systems.
Mike, did you see any messages such as... dir %lu size %lld exceeds block count %llu those should have tripped if it was going through the new code I added to patch this up.
with 2.6.9-43.EL I am getting: ls: reading directory /mnt/testarea/: Input/output error [root@dhcp59-116 ~]# uname -a Linux dhcp59-116.rdu.redhat.com 2.6.9-43.EL #1 Wed Jan 10 19:47:46 EST 2007 x86_64 x86_64 x86_64 GNU/Linux dmesg is showing me: attempt to access beyond end of device loop0: rw=0, want=14696842024, limit=24576 EXT2-fs error (device loop0): ext2_readdir: bad page in #2 (above 3 lines per invocation of the ls command) rebooting to re-try 42.0.7 once again.
I'm getting a continuous stream of the following with the 42.0.7 when trying to get a directory listing from the corrupted filesystem. I wonder if the fix for this ever got into the 42.0.x patch pool. I'm going to look through the source in a bit. EXT2-fs error (device loop0): ext2_readdir: bad page in #2 EXT2-fs error (device loop0): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=3237974016, inode=0, rec_len=0, name_len=0 EXT2-fs error (device loop0): ext2_readdir: bad page in #2 EXT2-fs error (device loop0): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=3237978112, inode=0, rec_len=0, name_len=0 EXT2-fs error (device loop0): ext2_readdir: bad page in #2 EXT2-fs error (device loop0): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=3237982208, inode=0, rec_len=0, name_len=0 EXT2-fs error (device loop0): ext2_readdir: bad page in #2 EXT2-fs error (device loop0): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=3237986304, inode=0, rec_len=0, name_len=0 EXT2-fs error (device loop0): ext2_readdir: bad page in #2 EXT2-fs error (device loop0): ext2_check_page: bad entry in directory #2: rec_len is smaller than minimal - offset=3237990400, inode=0, rec_len=0, name_len=0 sorry for jumping the gun on this one a bit too soon. In summary, 4.5beta (2.6.9-43.EL) looks ok, 42.0.7 is still exposed.
Ok, I diffed fs/ext2/ between the two kernels, and the difference here is that linux-2.6.9-ext2-readdir-fpos.patch is in 43 and not in 42.0.7 fuzzer tested kernels after that patch went in, so this is probably the first time we've seen the effects of fuzzed ext2 without -that- fix. Short answer, we probably need linux-2.6.9-ext2-readdir-fpos.patch in the errata as well. Thanks, -Eric
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0014.html