[PATCH] ext2: update inode ctime on rename()

The ext2fs filesystem on 2.2 and 2.6, as well as other filesystems
on 2.4 update the inode ctime on rename(). When this fix was applied
to 2.2.13, it was applied to the ext3 tree at the same time, but the
ext2 tree was forgotten. It was recently fixed in 2.6, but 2.4 was
forgotten again. Here's the fix.

First reported by Chris Siebenmann on 10 Jan 2004 !

Signed-off-by: Willy Tarreau <willy@w.ods.org>

- Willy
[PATCH] EXT2: avoid crashing by not dividing by zero.

backport a few checks from 2.6 to avoid dividing by zero on invalid
superblocks.
avoid semi-infinite loop when mounting bad ext2

This is a 2.4 backport of a linux-2.6 change by Andries Brouwer
(old-2.6-bkcvs commit c279c5343b1796bf1db4c0b4af2c99479a6575fe)

Commit log from 2.6 follows.

  The routine ext2_readdir() will, when reading a directory page
  returns an error, try the next page, without reporting the
  error to user space. That is bad, and the patch below changes that.

  In my case the filesystem was damaged, and ext2_readdir wanted
  to read 60000+ pages and wrote as many error messages to syslog
  ("attempt to access beyond end"), not what one wants.

  [no doubt a similar patch is appropriate for ext3]

Signed-off-by: dann frazier <dannf@hp.com>
ext2: skip pages past number of blocks in ext2_find_entry

This is a 2.4 backport of a linux-2.6 change by Eric Sandeen
(commit d8adb9cef7e406a9a82881695097c702bc98422f)

CVE-2006-6054 was assigned for this issue, which is easily reproducible in 2.4.
However, this changeset alone does not resolve the issue for 2.4 - two earlier
backports for ext2_readdir() are required.

Commit log from 2.6 follows.

  [PATCH] ext2: skip pages past number of blocks in ext2_find_entry

  This one was pointed out on the MOKB site:
  http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html

  If a directory's i_size is corrupted, ext2_find_entry() will keep
  processing pages until the i_size is reached, even if there are no more
  blocks associated with the directory inode.  This patch puts in some
  minimal sanity-checking so that we don't keep checking pages (and issuing
  errors) if we know there can be no more data to read, based on the block
  count of the directory inode.

  This is somewhat similar in approach to the ext3 patch I sent earlier this
  year.

Signed-off-by: dann frazier <dannf@hp.com>
ext2_readdir() filp->f_pos fix (try #2)

This patch reintroduces a fixed version of reverted commit
c30306fb287323591c854a0982d9fa5351859b45 from Dann Frazier :

  This is a 2.4 backport of a linux-2.6 change by Jan Blunck
  (old-2.6-bkcvs commit 2196b4744393d4f6c06fc4d63b98556d05b90933)

  Commit log from 2.6 follows.

    [PATCH] ext2_readdir() filp->f_pos fix

    If the whole directory is read, ext2_readdir() sets the f_pos to a multiple
    of the page size (because of the conditions of the outer for loop).  This
    sets the wrong f_pos for directory inodes on ext2 partitions with a block
    size differing from the page size.

Note from Glen :

  Perhaps the "filp->f_pos += le16_to_cpu(de->rec_len);" line should be
  outside of the if statement like the indentation implies?
  As it is, filp->f_pos gets corrupted if de->inode is ever zero...
  This could possibly explain why I had a few strange directory
  entries until I checked the filesystem with:
  e2fsck -D -F -f /dev/{ext2 partition}

This fix was confirmed by both Dann Frazier and Pascal Hambourg.

Note from Willy :

The code now differs from 2.6 only by commit
2d7f2ea9c989853310c7f6e8be52cc090cc8e66b which is only in 2.6.

The reporter, Al Masoud, provided the test case which could not be
reproduced on 2.4 (neither with nor without the fix above), so the
patch in question has *not* been applied to 2.4.

Dann will take the same approach for the Debian update.