linux-kernel - Re: Repercussions of overflow in get_next

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <30519.1431016421@jrobl>
Date:	Fri, 08 May 2015 01:33:41 +0900
From:	"J. R. Okajima" <hooanon05g@...il.com>
To:	Nikolay Borisov <n.borisov.lkml@...il.com>
Cc:	viro@...iv.linux.org.uk, "linux-kernel"@vger.kernel.org,
	linux-fsdevel@...r.kernel.org, spender@...ecurity.net
Subject: Re: Repercussions of overflow in get_next_ino()

Hello,

Nikolay Borisov:
> My question is what are the repercussions of get_next_ino overflowing 
> and at some point having possibly multiple inodes on my system with the 
> same i_ino id? And why is it safe to have the inode id's overflow and 
> wrap around?

I am afraid some applications won't work correctly.
As far as I know, ls(1) and find(1) don't show the file whose inum is
zero.

See also
	Subject: [PATCH v2] vfs: get_next_ino(), never inum=0
	Date: 2014-05-28 14:06:32
	http://marc.info/?l=linux-fsdevel&m=140128600801771&w=2
and their thread.

For tmpfs, I have another patch. Just FYI, here attached.


J. R. Okajima


Download attachment "a.patch.bz2" of type "application/x-bzip2" (2522 bytes)