linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 06 Nov 2006 14:50:58 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Jörn Engel <joern@...nheim.fh-wedel.de>
CC:	Jeff Layton <jlayton@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] make last_inode counter in new_inode 32-bit on kernels
 that offer x86 compatability

Jörn Engel wrote:
> On Mon, 6 November 2006 13:47:23 -0500, Jeff Layton wrote:
>> On Mon, 2006-11-06 at 11:22 -0700, Matthew Wilcox wrote:
>>> On Mon, Nov 06, 2006 at 01:12:05PM -0500, Jeff Layton wrote:
>>>> The attached patch remedies this by making the last_inode counter be an
>>>> unsigned int on kernels that have ia32 compatability mode enabled.
>>> ... and this only happens on ia64/x86_64 kernels, not sparc64, ppc64,
>>> s390x, parisc64 or mips64?
>> Here's a new (untested) patch that replaces the ia32 specific
>> compatability mode defines with CONFIG_COMPAT, as suggested by Matthew.
> 
> While you're at it, how about making last_ino per-sb instead of
> system-wide?  ino collisions after a wrap are just as bad as inos
> beyond 32bit.  And this should be a fairly simple method to reduce the
> risk.

Using a global counter for multiple filesystems should actually -reduce-
the chance of a collision on the same filesystem, since after you wrap the
recycled number may go to a different filesystem.

Simply making it a per-sb counter makes it worse, because wrapped inodes
will always go to the same filesystem.

To fix this properly, we'd need some sort of checking that the inode number
isn't currently being used on the filesystem in question before it's
assigned to the new inode.

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