Handle overflow in proc_get_long of sysctl
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-kernel-tests |
Fix Released
|
Undecided
|
Po-Hsu Lin | ||
linux (Ubuntu) |
Fix Released
|
Undecided
|
Po-Hsu Lin | ||
Xenial |
Fix Released
|
Undecided
|
Po-Hsu Lin | ||
Bionic |
Fix Released
|
Undecided
|
Po-Hsu Lin | ||
Cosmic |
Won't Fix
|
Undecided
|
Po-Hsu Lin | ||
Disco |
Fix Released
|
Undecided
|
Po-Hsu Lin | ||
Eoan |
Fix Released
|
Undecided
|
Po-Hsu Lin |
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 184467440737095
# cat /proc/sys/
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/
== 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:/
The attempt to set file-max to 2^64 will be rejected:
$ sudo sysctl -w -q fs.file-
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=
contacts=""
analysis=exit
<<<test_output>>>
incrementing stop
sysctl02 1 TINFO: timeout per run is 0h 5m 0s
sysctl02 1 TFAIL: /proc/sys/
sysctl02 2 TFAIL: /proc/sys/
sysctl02 3 TFAIL: /proc/sys/
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_
sysctl02 4 TINFO: loaded AppArmor profiles: none
Summary:
passed 0
failed 3
skipped 1
warnings 0
<<<execution_
initiation_
duration=0 termination_
cutime=2 cstime=1
<<<test_end>>>
ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: linux-image-
ProcVersionSign
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)
CVE References
tags: | added: linux-kvm |
Changed in ubuntu-kernel-tests: | |
assignee: | nobody → Po-Hsu Lin (cypressyew) |
status: | New → In Progress |
summary: |
- sysctl02_sh from ubuntu_ltp failed with Cosmic kernel + Handle overflow in proc_get_long of sysctl |
description: | updated |
Changed in linux (Ubuntu Cosmic): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Disco): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Xenial): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Cosmic): | |
status: | Fix Committed → Won't Fix |
Built a Cosmic generic kernel with AppArmor disabled, failures still can be seen in the test report: 4.18.0- 25-generic SECURITY_ APPARMOR is not set
$ grep -i apparmor /boot/config-
# CONFIG_
$ uname -a
Linux amaura 4.18.0-25-generic #26 SMP Tue Jun 25 07:49:54 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
<<<test_output>>> fs/file- max overflows and set to 0 fs/file- max overflows and set to 184467440737095 51615 fs/file- max overflows and set to 9223372036854775808
incrementing stop
sysctl02 1 TINFO: timeout per run is 0h 5m 0s
sysctl02 1 TFAIL: /proc/sys/
sysctl02 2 TFAIL: /proc/sys/
sysctl02 3 TFAIL: /proc/sys/
sysctl02 4 TCONF: kernel doesn't support KASAN
Summary:
passed 0
failed 3
skipped 1
warnings 0
And the commits mentioned in this test case does not exist in our kernel, so this is a valid kernel issue.