** Description changed: + == SRU Justification == + With the upper / lower boundary confined in bug 1834310, the file-max + is still suffering with overflow issue. + + This is because the simple_strtoul() used in proc_get_long() to parse + user input explicitly ignores overflows. So when you tried to put 2^64 + into file-max, it will: + # echo 18446744073709551616 > /proc/sys/fs/file-max + # cat /proc/sys/fs/file-max + 0 + + Which will cause your system to silently die behind your back. + + This issue was reported by the case 1 of the sysctl02 test in LTP: + sysctl02 1 TFAIL: /proc/sys/fs/file-max overflows and set to 0 + + + == Fix == + * 7f2923c4 (sysctl: handle overflow in proc_get_long) + + A new strtoul_lenient() was introduced here to solve this issue, with + extra check to notify userspace with -EINVAL. + + This patch can be cherry-picked into B/C/D/E, it needs some content + adjustment for X. + + == Test == + Test kernels could be found here: + https://people.canonical.com/~phlin/kernel/lp-1833935-proc_get_long/ + + The attempt to set file-max to 2^64 will be rejected: + $ sudo sysctl -w -q fs.file-max=18446744073709551616 + sysctl: setting key "fs.file-max": Invalid argument + + Tested and passed with these kernels on AMD64 KVM nodes. + + == Regression Potential == + Low, the newly introduced function strtoul_lenient() is just for + proc_get_long here. + + + == Original bug report == Test complains about apparmor enabled. As it's enabled by default, I think we might need to disable this test. Furthermore, this test will need kallsyms to be enabled, which is not for KVM kernels. <<<test_start>>> tag=sysctl02_sh stime=1561360893 cmdline="sysctl02.sh" contacts="" analysis=exit <<<test_output>>> incrementing stop sysctl02 1 TINFO: timeout per run is 0h 5m 0s sysctl02 1 TFAIL: /proc/sys/fs/file-max overflows and set to 0 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 sysctl02 4 TCONF: /proc/kallsyms not enabled sysctl02 4 TINFO: AppArmor enabled, this may affect test results sysctl02 4 TINFO: You can try to disable it with TST_DISABLE_APPARMOR=1 (requires super/root) sysctl02 4 TINFO: loaded AppArmor profiles: none Summary: passed 0 failed 3 skipped 1 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=33 corefile=no cutime=2 cstime=1 <<<test_end>>> ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.18.0-1015-kvm 4.18.0-1015.15 ProcVersionSignature: User Name 4.18.0-1015.15-kvm 4.18.20 Uname: Linux 4.18.0-1015-kvm x86_64 ApportVersion: 2.20.10-0ubuntu13.3 Architecture: amd64 Date: Mon Jun 24 07:21:41 2019 SourcePackage: linux-kvm UpgradeStatus: No upgrade log present (probably fresh install)
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1833935 Title: Handle overflow in proc_get_long of sysctl Status in ubuntu-kernel-tests: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Status in linux source package in Disco: In Progress Status in linux source package in Eoan: In Progress Bug description: == SRU Justification == With the upper / lower boundary confined in bug 1834310, the file-max is still suffering with overflow issue. This is because the simple_strtoul() used in proc_get_long() to parse user input explicitly ignores overflows. So when you tried to put 2^64 into file-max, it will: # echo 18446744073709551616 > /proc/sys/fs/file-max # cat /proc/sys/fs/file-max 0 Which will cause your system to silently die behind your back. This issue was reported by the case 1 of the sysctl02 test in LTP: sysctl02 1 TFAIL: /proc/sys/fs/file-max overflows and set to 0 == Fix == * 7f2923c4 (sysctl: handle overflow in proc_get_long) A new strtoul_lenient() was introduced here to solve this issue, with extra check to notify userspace with -EINVAL. This patch can be cherry-picked into B/C/D/E, it needs some content adjustment for X. == Test == Test kernels could be found here: https://people.canonical.com/~phlin/kernel/lp-1833935-proc_get_long/ The attempt to set file-max to 2^64 will be rejected: $ sudo sysctl -w -q fs.file-max=18446744073709551616 sysctl: setting key "fs.file-max": Invalid argument Tested and passed with these kernels on AMD64 KVM nodes. == Regression Potential == Low, the newly introduced function strtoul_lenient() is just for proc_get_long here. == Original bug report == Test complains about apparmor enabled. As it's enabled by default, I think we might need to disable this test. Furthermore, this test will need kallsyms to be enabled, which is not for KVM kernels. <<<test_start>>> tag=sysctl02_sh stime=1561360893 cmdline="sysctl02.sh" contacts="" analysis=exit <<<test_output>>> incrementing stop sysctl02 1 TINFO: timeout per run is 0h 5m 0s sysctl02 1 TFAIL: /proc/sys/fs/file-max overflows and set to 0 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 sysctl02 4 TCONF: /proc/kallsyms not enabled sysctl02 4 TINFO: AppArmor enabled, this may affect test results sysctl02 4 TINFO: You can try to disable it with TST_DISABLE_APPARMOR=1 (requires super/root) sysctl02 4 TINFO: loaded AppArmor profiles: none Summary: passed 0 failed 3 skipped 1 warnings 0 <<<execution_status>>> initiation_status="ok" duration=0 termination_type=exited termination_id=33 corefile=no cutime=2 cstime=1 <<<test_end>>> ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: linux-image-4.18.0-1015-kvm 4.18.0-1015.15 ProcVersionSignature: User Name 4.18.0-1015.15-kvm 4.18.20 Uname: Linux 4.18.0-1015-kvm x86_64 ApportVersion: 2.20.10-0ubuntu13.3 Architecture: amd64 Date: Mon Jun 24 07:21:41 2019 SourcePackage: linux-kvm UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1833935/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
