On Tue, Oct 16, 2018 at 3:33 PM, Christian Brauner <christian@xxxxxxxxxx> wrote: > Hey, > > Here is v3 of this patchset. Changelogs are in the individual commits. Thanks! These look good. Andrew, can you take these? -Kees > > Currently, when writing > > echo 18446744073709551616 > /proc/sys/fs/file-max > > /proc/sys/fs/file-max will overflow and be set to 0. That quickly > crashes the system. > > The first version of this patch intended to detect the overflow and cap > at ULONG_MAX. However, we should not do this and rather return EINVAL on > overflow. The reasons are: > - this aligns with other sysctl handlers that simply reject overflows > (cf. [1], [2], and a bunch of others) > - we already do a partial fail on overflow right now > Namely, when the TMPBUFLEN is exceeded. So we already reject values > such as 184467440737095516160 (21 chars) but accept values such as > 18446744073709551616 (20 chars) but both are overflows. So we should > just always reject 64bit overflows and not special-case this based on > the number of chars. > > (This patchset is in reference to https://lkml.org/lkml/2018/10/11/585.) > > Thanks! > Christian > > [1]: fb910c42cceb ("sysctl: check for UINT_MAX before unsigned int min/max") > [2]: 196851bed522 ("s390/topology: correct topology mode proc handler") > > Christian Brauner (2): > sysctl: handle overflow in proc_get_long > sysctl: handle overflow for file-max > > kernel/sysctl.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 46 insertions(+), 1 deletion(-) > > -- > 2.17.1 > -- Kees Cook Pixel Security
