linux-kernel - Upper limit for sysctl fs.file-max

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

Message-ID: <e980436491d144bfbd1410a02333ebfc@AcuMS.aculab.com>
Date:   Wed, 1 May 2019 09:53:52 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Upper limit for sysctl fs.file-max

The normal default for fs.file-max (the maximum number of file structures)
is 1/10240th of the available memory.

However it seems to be possible to set fs.file-max to any value
up to 2^64-1.
While all 'large' values are effectively the same this seems rather
excessive here.

Problems arrive when any shell scripts (or anything else that
only really has signed 64bit numbers) try to process values above
2^63-1 as these cause errors and/or other unexpected actions.

ISTM that the values of a lot of sysctl parameters should be limited
to avoid such problems.

We've hit this because something is awry in the 5.0 kernel in
ubuntu 19.04.
Booting the failing userspace with a 5.1-rcx kernel is ok.
Nothing looks wrong with the object code for the function that
sets the default, and the last thing it does is divide by 10
so it is difficult for it to generate -1.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)