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 15:36:56 -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 14:50:58 -0600, Eric Sandeen wrote:
>>> 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.
> 
> You're missing something.  The chance for a collision _per wrap_ is
> reduced, as you said.  But the number of wraps goes up.  Overall and
> for large numbers, the two effects compensate each other.

Well, one concern is an intentional exploit.  In which case "longer
time" and "shorter time" don't matter -so- much.  If it can happen at
all, it's bad, period.

OTOH if one filesystem (say, pipes) can wrap the numbers very quickly,
while other spaces are otherwise more immune, then having it global puts
everything using it at a bit more risk.

*shrug* I dunno, it's probably not worth arguing this point, it needs to
be fixed properly in any case. :)

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