Letting the following set of commands run long enough on a machine with
at least 3 CPU threads causes soft lockups in the kernel:
(cd /sys/fs/selinux/; while true; do find >/dev/null 2>&1; done) &
(cd /sys/fs/selinux/; while true; do find >/dev/null 2>&1; done) &
(cd /sys/fs/selinux/; while true; do find >/dev/null 2>&1; done) &
while true; do load_policy; echo -n .; sleep 0.1; done
The problem is that sel_remove_entries() removes the old selinuxfs
entries using d_genocide() + shrink_dcache_parent(), which is not safe
to do on live trees that are still exposed to userspace.
Specifically, it races with dcache_readdir(), which expects that while a
dentry's inode is locked, its (positive) children cannot get unlisted,
because both unlink() and rmdir() lock the parent inode first.
Therefore, use the newly introduced d_genocide_safe() instead of
d_genocide(), which fixes this issue.
Bug tracker links:
* SELinux GitHub: https://github.com/SELinuxProject/selinux-kernel/issues/42
* Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1510603
Fixes: ad52184b705c ("selinuxfs: don't open-code d_genocide()")
Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
---
security/selinux/selinuxfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index e6c7643c3fc0..58d1949e5faf 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -1317,7 +1317,7 @@ static const struct file_operations sel_commit_bools_ops = {
static void sel_remove_entries(struct dentry *de)
{
- d_genocide(de);
+ d_genocide_safe(de);
shrink_dcache_parent(de);
}
--
2.21.0
