linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <554B5AE1.4060901@gmail.com>
Date:	Thu, 07 May 2015 15:30:25 +0300
From:	Nikolay Borisov <n.borisov.lkml@...il.com>
To:	viro@...iv.linux.org.uk
CC:	"linux-kernel"@vger.kernel.org, linux-fsdevel@...r.kernel.org,
	spender@...ecurity.net
Subject: Repercussions of overflow in get_next_ino()

Hello,

get_next_ino would allocate a number between 0...2^32 - 1 to be used as 
an inode number. The implementation of this mechanism relies on an 
unsigned int which is 32 bits. On one server I'm observing that every 
couple of months grsec complains that the percpu variable last_ino 
overflows (due to shared_last_ino) being incremented to the limit of a 
32 bit value and then then the machine becomes unstable due to grsec 
starting to kill processes. Now, I understand this isssue stems from the 
fact how grsec detects the overflow.

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?

Would simply changing the inode numbering code work with 64 bit value 
remedy the situation or would it require a more involved fix?

Regards,
Nikolay
--
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/