the NULL deref on umount in the 3.9.0-rc7 kernel
Hi All
I would like to report the NULL deref on umount. Tested it in linux kernel 3.7.10 and it's still in the 3.9.0-rc7. /
Test-case description:
Mount cgroup filesystem with xattr option and create inside root cgroup another hierarchy.
Then set extended attribute to any files within root hierarchy or sub hierarchie.
Then remove (rmdir) sub hierarchy and call umount cgroup filesystem. Afterthat, umount crash the kernel.
Also, if you don't remove sub hierarchy (steps 1.4 & 2.9 in examples below), calling umount will produce nothing except that cgroup filesystem will be unmounted (no cgroup files in the directory) but with error: cgroups continue working, while call mount again to get control access to running cgroups will produce error, such as filesystem is already mounted, but in /proc/mounts you don't have such mount point. And there is no way to get control access back to the running cgroups, except for reboot.
Here are some manual methods which will reproduce Linux crash.
1. One way to reproduce this fault:
1.1% mount -t cgroup cgroot_test -o xattr /sys/fs/cgroup
1.2% mkdir /sys/fs/cgroup/test_subsys
1.3% setfattr -n trusted.value -v test_value /sys/fs/cgroup/tasks
1.4% rmdir /sys/fs/cgroup/test_subsys
1.5% umount cgroot_test
2. Another way:
2.1% mount -t tmpfs cgroup_root /sys/fs/cgroup
2.2% mkdir /sys/fs/cgroup/rg1
2.3% mount -t cgroup -o cpuset,xattr hier1 /sys/fs/cgroup/rg1
2.4% cd /sys/fs/cgroup/rg1
2.5% mkdir test_subsys
2.6% setfattr -n trusted.value -v test_value ./tasks
2.7% setfattr -n trusted.value -v test_value ./test_subsys
2.8% setfattr -n trusted.value -v test_value ./test_subsys/tasks
2.9% rmdir test_subsys
2.10% cd ../
2.11% umount hier1
Thanks,
Alexey Kodanev
/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · On 2013/4/18 19:37, [email protected]…
Hi All
I would like to report the NULL deref on umount. Tested it in linux kernel 3.7.10 and it's still in the 3.9.0-rc7. /
Test-case description:
Mount cgroup filesystem with xattr option and create inside root cgroup another hierarchy.
Then set extended attribute to any files within root hierarchy or sub hierarchie.
Then remove (rmdir) sub hierarchy and call umount cgroup filesystem. Afterthat, umount crash the kernel.Also, if you don't remove sub hierarchy (steps 1.4 & 2.9 in examples below), calling umount will produce nothing except that cgroup filesystem will be unmounted (no cgroup files in the directory) but with error: cgroups continue working, while call mount again to get control access to running cgroups will produce error, such as filesystem is already mounted, but in
/proc/mountsyou don't have such mount point. And there is no way to get control access back to the running cgroups, except for reboot.Here are some manual methods which will reproduce Linux crash.
Quoted 8 lines
1. One way to reproduce this fault:
1.1% mount -t cgroup
cgroot_test-o xattr/sys/fs/cgroup1.2% mkdir/sys/fs/cgroup/test_subsys
1.3% setfattr -n trusted.value -vtest_value/sys/fs/cgroup/tasks1.4% rmdir/sys/fs/cgroup/test_subsys
1.5% umountcgroot_test
Thanks for the report!
A fix will be followed soon.
Quoted 13 lines · On 2013/4/18 19:37, [email protected]…
Hi All
I would like to report the NULL deref on umount. Tested it in linux kernel 3.7.10 and it's still in the 3.9.0-rc7. /
Test-case description:
Mount cgroup filesystem with xattr option and create inside root cgroup another hierarchy.
Then set extended attribute to any files within root hierarchy or sub hierarchie.
Then remove (rmdir) sub hierarchy and call umount cgroup filesystem. Afterthat, umount crash the kernel.Also, if you don't remove sub hierarchy (steps 1.4 & 2.9 in examples below), calling umount will produce nothing except that cgroup filesystem will be unmounted (no cgroup files in the directory) but with error: cgroups continue working, while call mount again to get control access to running cgroups will produce error, such as filesystem is already mounted, but in
/proc/mountsyou don't have such mount point. And there is no way to get control access back to the running cgroups, except for reboot.Here are some manual methods which will reproduce Linux crash.
Quoted 8 lines
1. One way to reproduce this fault:
1.1% mount -t cgroup
cgroot_test-o xattr/sys/fs/cgroup1.2% mkdir/sys/fs/cgroup/test_subsys
1.3% setfattr -n trusted.value -vtest_value/sys/fs/cgroup/tasks1.4% rmdir/sys/fs/cgroup/test_subsys
1.5% umountcgroot_test
Thanks for the report!
A fix will be followed soon.