[PATCH 0/3] new_inode_autonum: intro -- ensure uniqueness of i_ino and try to prevent st_ino EOVERFLOW in userspace

[Jeff Layton <jlayton@redhat.com>]

This started as a rather simple problem. glibc uses fstat64() internally
when making a stat() call. If the st_ino field returned by this call
does not fit in the buffer allocated by the program, glibc (rightly)
generates an EOVERFLOW in userspace. This is generally only a problem
when the program is compiled without -D_FILE_OFFSET_BITS=64.

The kernel declares ino_t to be an unsigned long which is generally
32-bits on 32-bit kernels and 64-bits on 64-bit kernels. The new_inode
function has a static unsigned long counter that it uses to assign out
i_ino values.

On a 64-bit kernel, the value in this counter eventually becomes too
large to fit in 32-bits, and glibc starts throwing EOVERFLOW errors to
programs compiled without large file offsets. This creates a situation
where such a program will work fine on a 32-bit kernel, but when run on
a 64-bit kernel it will eventually start falling down.

We can't do much about this on filesystems that have true 64-bit inodes,
but on filesystems that get "pseudo_inode" values via new_inode or
iunique, we should attempt to make them fit in a 32-bit value.

While fixing this, we discovered that many filesystems seem to blindly
accept the i_ino value given by new_inode. new_inode makes no actual
check to see if an i_ino value is unique, so once the counter overflows
you can end up with more than one inode with the same i_ino value.

The following set of patches should remedy both of these problems. While
these are arguably security-related, these patches are probably better
suited to 2.6.20 than anything earlier.

-- Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/