linux-kernel - [PATCH 0/3] new_inode_autonum: intro -- ensure uniqueness of i_ino and try to prevent st

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 09 Nov 2006 10:24:36 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...l.org
Subject: [PATCH 0/3] new_inode_autonum: intro -- ensure uniqueness of i_ino
	and try to prevent st_ino EOVERFLOW in userspace

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/