Skip to contentSkip to conversation

the NULL deref on umount in the 3.9.0-rc7 kernel

DISCUSSION [email protected] 2 participants 3 messages Apr 18, 2013 – Apr 19, 2013 1 message not in the archive cgroup

lore
Share & tools
lore
#0 lore raw

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]

#2 lore raw
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/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.

Quoted 8 lines

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

Thanks for the report!

A fix will be followed soon.

#3 lore raw
In reply to a message not in the archive
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/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.

Quoted 8 lines

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

Thanks for the report!

A fix will be followed soon.