linux-kernel - [PATCH] make last_inode counter in new_inode 32-bit on kernels that offer x86 compatability

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:	Mon, 06 Nov 2006 13:12:05 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	linux-fsdevel@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH] make last_inode counter in new_inode 32-bit on kernels
	that offer x86 compatability

Some (generally not disk-based) filesystems use the new_inode() function
to allocate and populate inode structs. This function uses a static
unsigned long counter to populate i_ino. On most 64-bit platforms, this
is a 64-bit integer, but on ia32, this is a 32-bit int.

If stat() is called from a 32-bit program that was not compiled with
-D_FILE_OFFSET_BITS=64 on one of these inodes, then glibc will generate
an EOVERFLOW error in userspace (since the st_ino returned by the stat64
call won't fit in the old-style stat struct).

This creates a situation where these programs will run just fine on a
32-bit kernel, but will eventually start falling down with EOVERFLOW
errors on a 64-bit kernel. One way to reproduce this is to write a
program that repeatedly calls pipe() and then does an fstat() on one of
the pipe filehandles, and compile the program as a 32-bit app w/o
-D_FILE_OFFSET_BITS=64. Eventually, the fstat will consistently fail
with an EOVERFLOW.

The attached patch remedies this by making the last_inode counter be an
unsigned int on kernels that have ia32 compatability mode enabled.

My rationale is that we're eventually going to overflow this counter
regardless. This does make it happen sooner, but this is no worse that
what already happens on ia32.

Signed-off-by: Jeff Layton <jlayton@...hat.com>

--- linux-2.6/fs/inode.c.lastino
+++ linux-2.6/fs/inode.c
@@ -524,7 +524,11 @@ repeat:
  */
 struct inode *new_inode(struct super_block *sb)
 {
+#if (defined CONFIG_IA32_EMULATION || defined CONFIG_IA32_SUPPORT)
+	static unsigned int last_ino;
+#else
 	static unsigned long last_ino;
+#endif
 	struct inode * inode;
 
 	spin_lock_prefetch(&inode_lock);


-
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/