[B][C][SRU][PATCH 0/2] Handle overflow for file-max

[Po-Hsu Lin]

== SRU Justification ==
Currently, when writing
   echo 18446744073709551616 > /proc/sys/fs/file-max

/proc/sys/fs/file-max will overflow and be set to 0 and make the system
stuck with "Too many open files in system" error within seconds.

The upper and lower limit need to be defined properly to avoid this.

This failure was reported by the case 2 and 3 of the sysctl02 test in LTP:
sysctl02 2 TFAIL: /proc/sys/fs/file-max overflows and set to 18446744073709551615
sysctl02 3 TFAIL: /proc/sys/fs/file-max overflows and set to 9223372036854775808

== Fix ==
* 32a5ad9c sysctl: handle overflow for file-max
* 9002b214 kernel/sysctl.c: fix out-of-bounds access when setting file-max

These patches can be cherry-picked into B/C.
They have already been applied in X/D from stable update process.

== Test ==
Test kernel could be found here:
https://people.canonical.com/~phlin/kernel/lp-1834310-file-max/

Tested OK on KVM nodes with the following command (extracted from the
sysctl02 test case in LTP):
  $ cat /proc/sys/fs/file-max
  $ sudo sysctl -w -q fs.file-max=18446744073709551615
  $ cat /proc/sys/fs/file-max
  $ sudo sysctl -w -q fs.file-max=9223372036854775808
  $ cat /proc/sys/fs/file-max

All three file-max output should be identical with the patched kernel.

This is because the file-max value is parsed via
__do_proc_doulongvec_minmax(), which does not report error when min or
max are exceeded but it will just keep the old value instead.

== Regression Potential ==
Low, just adding boundaries to the file-max.
And it's been applied in some of our kernels for a while.

Christian Brauner (1):
  sysctl: handle overflow for file-max

Will Deacon (1):
  kernel/sysctl.c: fix out-of-bounds access when setting file-max

 kernel/sysctl.c | 4 ++++
 1 file changed, 4 insertions(+)

-- 
2.7.4